2016-05-12 00:01 MistahDarcy has quit [Ping timeout: 250 seconds]
2016-05-12 00:44 MistahDarcy has joined #qi-hardware
2016-05-12 01:15 arossdotme has quit [Ping timeout: 252 seconds]
2016-05-12 01:30 MistahDarcy has quit [Ping timeout: 260 seconds]
2016-05-12 01:31 MistahDarcy has joined #qi-hardware
2016-05-12 01:56 archang has joined #qi-hardware
2016-05-12 01:58 sandeepkr has quit [Read error: Connection reset by peer]
2016-05-12 01:59 sandeepkr has joined #qi-hardware
2016-05-12 02:05 <whitequark> DocScrutinizer51: set_transient_window
2016-05-12 02:12 archang has quit [Ping timeout: 260 seconds]
2016-05-12 02:34 arossdotme has joined #qi-hardware
2016-05-12 02:57 fengling has joined #qi-hardware
2016-05-12 03:01 sandeepkr has quit [Read error: Connection reset by peer]
2016-05-12 03:02 sandeepkr has joined #qi-hardware
2016-05-12 03:03 sandeepkr has quit [Read error: Connection reset by peer]
2016-05-12 03:03 xiangfu has joined #qi-hardware
2016-05-12 03:38 sb0 has quit [Quit: Leaving]
2016-05-12 03:59 DocScrutinizer05 has quit [Disconnected by services]
2016-05-12 04:00 DocScrutinizer05 has joined #qi-hardware
2016-05-12 04:49 xiangfu has quit [Ping timeout: 276 seconds]
2016-05-12 05:05 sandeepkr has joined #qi-hardware
2016-05-12 05:14 xiangfu has joined #qi-hardware
2016-05-12 05:42 fengling has quit [Ping timeout: 240 seconds]
2016-05-12 06:00 sandeepkr has quit [Ping timeout: 276 seconds]
2016-05-12 06:11 fengling has joined #qi-hardware
2016-05-12 06:28 sandeepkr has joined #qi-hardware
2016-05-12 06:43 sandeepkr has quit [Read error: No route to host]
2016-05-12 06:44 sandeepkr has joined #qi-hardware
2016-05-12 07:00 xiangfu has quit [Ping timeout: 276 seconds]
2016-05-12 07:00 xiangfu has joined #qi-hardware
2016-05-12 08:26 pcercuei has joined #qi-hardware
2016-05-12 08:28 <larsc> whitequark: you always know these things. Do C compilers have rules for alignement of arrays that puts the start of the array at an address that is more aligned than the array entry size?
2016-05-12 08:30 <whitequark> as far as I know, the array entry size does not matter, only whether the members go in the right places
2016-05-12 08:31 <whitequark> consider this: if you are allocating memory for an array (or a single struct, even) with malloc, malloc is not going to give you highly aligned memory
2016-05-12 08:31 <whitequark> there's no reason the linker should
2016-05-12 08:31 <larsc> I have an array of pointers
2016-05-12 08:31 <whitequark> (and malloc will easily give you memory that's not aligned enough for some operations, such as SSE, which needs 16-byte alignment, but malloc will commonly gve you 8)
2016-05-12 08:31 <larsc> if I have only one entry it's simply aligned to the pointer size
2016-05-12 08:32 <larsc> but if I have more it is aligned at a larger size
2016-05-12 08:32 <whitequark> how do you determine how is it aligned?
2016-05-12 08:32 <larsc> up to 4 times the pointer size
2016-05-12 08:32 <whitequark> nm?
2016-05-12 08:32 <larsc> yes
2016-05-12 08:32 <whitequark> I think this is a compiler-specific optimization
2016-05-12 08:33 <larsc> what I'm trying to do is to put them in a special section, so I don't have to maintain a global list of all these pointers
2016-05-12 08:33 <larsc> and what I'm seeing right now is that there are sometimes gaps
2016-05-12 08:33 <larsc> nothing that can't be handled, but still not so nice
2016-05-12 08:33 <whitequark> ohh
2016-05-12 08:34 <larsc> or do you think this is a bad idea in general?
2016-05-12 08:34 <whitequark> yes, to do this you need to explicitly call out the alignment on the global
2016-05-12 08:34 <whitequark> no, it's a perfectluy fine idea
2016-05-12 08:34 <whitequark> libc does this
2016-05-12 08:34 <whitequark> for .init/.fini
2016-05-12 08:34 <whitequark> just use __attributes__((align(sizeof(void*))))
2016-05-12 08:34 <whitequark> align(...),section(".whatever")
2016-05-12 08:35 <whitequark> http://llvm.org/docs/LangRef.html#global-variables
2016-05-12 08:35 <whitequark> An explicit alignment may be specified for a global, which must be a power of 2. If not present, or if the alignment is set to zero, the alignment of the global is set by the target to whatever it feels convenient. If an explicit alignment is specified, the global is forced to have exactly that alignment. Targets and optimizers are not allowed to over-align the global if the global has an assigned section. In this case, the extra alignment c
2016-05-12 08:35 <whitequark> exactly describes your use case
2016-05-12 08:35 sb0 has joined #qi-hardware
2016-05-12 08:36 <larsc> ok, thanks, that's quite helpful
2016-05-12 08:41 <larsc> ok, works perfectly, with explicit alignment the gaps are gone
2016-05-12 08:43 <larsc> Do you know how portable such an approach is? This is for libsigrok
2016-05-12 08:52 <whitequark> this will work on gcc and clang
2016-05-12 08:52 <whitequark> well
2016-05-12 08:52 <whitequark> the code to put it into a section is just as portable as the alignment attribute
2016-05-12 08:52 <whitequark> so this specific part creates no new problems
2016-05-12 08:54 <larsc> I mean the approach of using sections as arrays, do you can think of any platform where it will break
2016-05-12 08:55 <whitequark> msvc
2016-05-12 08:55 <whitequark> you'll have to use __declspec(allocate)
2016-05-12 08:57 <pcercuei> < whitequark> just use __attributes__((align(sizeof(void*))))
2016-05-12 08:57 <pcercuei> not portable
2016-05-12 08:57 <pcercuei> dammit, you just said it
2016-05-12 08:58 <pcercuei> I should read to the end :)
2016-05-12 08:59 <larsc> with it's lack of support for current C standards msvc is probably not a target anyway
2016-05-12 08:59 <larsc> thanks
2016-05-12 09:02 <wpwrak> everything seems to converge to gcc anyway
2016-05-12 09:06 jwhitmore has joined #qi-hardware
2016-05-12 09:14 <larsc> whitequark: does this look ok to you? https://github.com/analogdevicesinc/libsigrok/commit/0a66432e5cd34bf8b6d9d144b0a7ca182b290816#diff-88d499a1a7ecc6d02d08a96525e502e5
2016-05-12 09:14 <larsc> and https://github.com/analogdevicesinc/libsigrok/commit/0a66432e5cd34bf8b6d9d144b0a7ca182b290816#diff-7af547b52769371de74af0bfca268a62
2016-05-12 09:21 <whitequark> I don't see anything wrong with it
2016-05-12 09:22 <larsc> ok, thanks.
2016-05-12 09:31 xiangfu has quit [Ping timeout: 240 seconds]
2016-05-12 09:36 xiangfu has joined #qi-hardware
2016-05-12 10:07 <pcercuei> larsc, GCC adds the __start_$(section) / __stop_$(section) symbols automatically?
2016-05-12 10:11 sb0 has quit [Quit: Leaving]
2016-05-12 10:19 <larsc> yes
2016-05-12 10:21 <pcercuei> nice
2016-05-12 10:28 <whitequark> does it?
2016-05-12 10:28 <whitequark> I'm pretty sure it doesn't, that's the default glibc linker script
2016-05-12 10:28 <whitequark> you might want to check that on non-glibc systems
2016-05-12 10:32 fengling has quit [Quit: WeeChat 1.4]
2016-05-12 10:32 fengling has joined #qi-hardware
2016-05-12 10:32 <DocScrutinizer05> to avoid any gaps, wrap the whole data section up into one hige struct
2016-05-12 10:33 <DocScrutinizer05> huge
2016-05-12 10:33 <DocScrutinizer05> so it becomes one entity without gaps in between
2016-05-12 10:35 <wpwrak> whitequark: i'd also be surprised if the compiler did that. at least i never encountered such
2016-05-12 10:35 <wpwrak> DocScrutinizer05: the whole idea is to be able to distribute those things :)
2016-05-12 10:35 <whitequark> DocScrutinizer05: doesn't work if the whole point is to assemble it from multiple files
2016-05-12 10:36 <DocScrutinizer05> rrright
2016-05-12 10:36 <wpwrak> and it's a very well-established practice to do this. e.g., the linux kernel heavily makes use of this
2016-05-12 10:36 <DocScrutinizer05> but then you need to depend on the linker (or compiler *maybe*) since you can't coordinate stuff across files
2016-05-12 10:36 <larsc> well, it's definitly not the compiler because the compiler can't do that
2016-05-12 10:36 <DocScrutinizer05> wpwrak: this?
2016-05-12 10:37 <DocScrutinizer05> larsc: that's what I think too
2016-05-12 10:37 <whitequark> yes. you need to depend on the linker.
2016-05-12 10:37 <whitequark> if you don't provide your own linker script, the default linker script does something like this
2016-05-12 10:37 <wpwrak> DocScrutinizer05: this = special sections to collect lists of items
2016-05-12 10:37 <whitequark> alternatively, you can go the crtbegin.o/crtend.o way
2016-05-12 10:37 <DocScrutinizer05> aaah
2016-05-12 10:38 <whitequark> where you put a sentinel into a begin.o file and an end.o file
2016-05-12 10:38 <whitequark> since linkers assemble sections in the order that they appear on the command line
2016-05-12 10:38 <whitequark> this is somewhat more portable than depending on specific glibc linker script
2016-05-12 10:39 <whitequark> larsc: I think __attribute__((constructor)) will allow you to do the same without the mess of working with sections directly
2016-05-12 10:40 <whitequark> i.e. it will work on all practical ELF platforms regardless of libc
2016-05-12 10:41 <whitequark> oh and __attribute__((constructor)) also works on OS X
2016-05-12 10:41 <whitequark> soo... i think you're covered, really
2016-05-12 10:42 fengling has quit [Ping timeout: 240 seconds]
2016-05-12 10:42 <wpwrak> linker scripts are a bit suckish if you only want to change some small detail, like adding a new set of sections, but then you have to do all the rest as well. and often enough, much of the rest doesn't really make sense to you.
2016-05-12 10:43 fengling has joined #qi-hardware
2016-05-12 10:45 <wpwrak> whitequark: but attribute((constructor)) means that it gets executed, no ? so that wouldn't work in lars' case
2016-05-12 10:45 <larsc> hm I don't like constructor that much
2016-05-12 10:45 <whitequark> it will get executed and register itself in some global linked list or w/e
2016-05-12 10:45 <larsc> well you can have a function that adds things to a linked list or whatever
2016-05-12 10:45 <whitequark> exactly
2016-05-12 10:45 <wpwrak> (at least no without a detour)
2016-05-12 10:46 <larsc> but I don't like that
2016-05-12 10:46 <whitequark> it's cleaner because you don't rely on __start and otherwise it's the same thing
2016-05-12 10:46 <larsc> at least as long as long as the section approach works
2016-05-12 10:46 <whitequark> global constructors are generally evil but if the only thing you need is to set a single pointer
2016-05-12 10:46 <whitequark> theyre ok
2016-05-12 10:47 <larsc> it's hard to find actual documentation on the __start __stop symbols
2016-05-12 10:48 <larsc> I was searching how to add new sections to the linker script, without re-writing the default linker script and that's what I found instead
2016-05-12 10:49 <whitequark> this will break on OS X.
2016-05-12 10:49 <whitequark> since OS X has no linker scripts
2016-05-12 10:49 <whitequark> but, OS X supports constructor attribute
2016-05-12 10:49 <whitequark> (anything that supports C++ properly does)
2016-05-12 10:52 <larsc> hm
2016-05-12 10:52 <larsc> http://stackoverflow.com/questions/17669593/how-to-get-a-pointer-to-a-binary-section-in-mac-os-x
2016-05-12 10:53 <wpwrak> larsc: from the ld documentation: "If the linker cannot recognize the format of an object file, it will assume that it is a linker script. A script specified in this way augments the main linker script used for the link"
2016-05-12 10:54 <whitequark> larsc: yes. either of those works. or just use constructor.
2016-05-12 11:03 <larsc> wpwrak: yes, it's terrible
2016-05-12 11:03 <larsc> or is it?
2016-05-12 11:04 <wpwrak> larsc: this looks as if it was the answer to your question of how to add things to a linker script without having to rewrite the whole mess
2016-05-12 11:05 <wpwrak> (note: just spotted this, so i don't know how well it works in practice)
2016-05-12 11:05 <larsc> hm
2016-05-12 11:05 <wpwrak> also, if mac os x really has no linker scripts, and you care about supporting that platform, then constructors may indeed be the only way
2016-05-12 11:28 <whitequark> wpwrak: os x has hardcoded start/end symbols
2016-05-12 11:28 <whitequark> theyre just... different
2016-05-12 11:28 <whitequark> you could use constructors and work anywhere c++ and gcc-like attributes work, which is a lot of places
2016-05-12 11:28 <whitequark> and never think about that shit again
2016-05-12 11:47 <larsc> wpwrak: it looks as if you put INSERT AFTER $section into your custom linker script it wil also only augment the default
2016-05-12 11:48 <larsc> whitequark: but micro optimizations!
2016-05-12 11:49 <whitequark> what
2016-05-12 11:49 <whitequark> have you *seen* how much shit the dynamic linker does
2016-05-12 11:49 fengling has quit [Ping timeout: 240 seconds]
2016-05-12 11:51 <larsc> no
2016-05-12 11:51 <larsc> luckily I never had to
2016-05-12 11:52 <DocScrutinizer05> hehe
2016-05-12 11:52 <whitequark> you can start by stracing it
2016-05-12 11:52 <whitequark> anything dynamically linked
2016-05-12 11:52 <DocScrutinizer05> get towels for the bleeding eyes?
2016-05-12 12:00 <whitequark> transfusions
2016-05-12 12:32 sb0 has joined #qi-hardware
2016-05-12 12:43 xiangfu has quit [Ping timeout: 276 seconds]
2016-05-12 12:45 xiangfu has joined #qi-hardware
2016-05-12 13:39 fengling has joined #qi-hardware
2016-05-12 13:44 fengling has quit [Ping timeout: 240 seconds]
2016-05-12 14:11 bzb has joined #qi-hardware
2016-05-12 14:30 xiangfu has quit [Ping timeout: 244 seconds]
2016-05-12 14:35 xiangfu has joined #qi-hardware
2016-05-12 14:36 bzb has quit [Quit: Leaving]
2016-05-12 15:32 doomlord_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
2016-05-12 15:36 doomlord_ has joined #qi-hardware
2016-05-12 15:43 fengling has joined #qi-hardware
2016-05-12 15:47 fengling has quit [Ping timeout: 240 seconds]
2016-05-12 15:55 sb0 has quit [Read error: Connection reset by peer]
2016-05-12 16:17 doomlord_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
2016-05-12 16:23 xiangfu has quit [Remote host closed the connection]
2016-05-12 16:25 doomlord_ has joined #qi-hardware
2016-05-12 16:27 sb0 has joined #qi-hardware
2016-05-12 16:30 doomlord_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
2016-05-12 16:35 doomlord_ has joined #qi-hardware
2016-05-12 16:44 fengling has joined #qi-hardware
2016-05-12 16:49 fengling has quit [Ping timeout: 240 seconds]
2016-05-12 16:56 jwhitmore has quit [Ping timeout: 260 seconds]
2016-05-12 17:27 pcercuei has quit [Quit: leaving]
2016-05-12 17:39 <DocScrutinizer05> http://www.experten-arbeit-stärken.de/
2016-05-12 17:59 wildlander has joined #qi-hardware
2016-05-12 18:46 jwhitmore has joined #qi-hardware
2016-05-12 18:47 fengling has joined #qi-hardware
2016-05-12 18:52 pcercuei has joined #qi-hardware
2016-05-12 18:52 fengling has quit [Ping timeout: 240 seconds]
2016-05-12 19:02 sandeepkr has quit [Ping timeout: 265 seconds]
2016-05-12 19:17 sandeepkr has joined #qi-hardware
2016-05-12 19:18 rjeffries has joined #qi-hardware
2016-05-12 19:49 fengling has joined #qi-hardware
2016-05-12 19:53 fengling has quit [Ping timeout: 240 seconds]
2016-05-12 20:01 rjeffries has quit [Ping timeout: 246 seconds]
2016-05-12 20:09 jwhitmore has quit [Ping timeout: 246 seconds]
2016-05-12 20:39 pcercuei has quit [Quit: leaving]
2016-05-12 21:51 wildlander has quit [Quit: Saliendo]
2016-05-12 21:52 fengling has joined #qi-hardware
2016-05-12 21:56 fengling has quit [Ping timeout: 240 seconds]
2016-05-12 22:24 sandeepkr_ has joined #qi-hardware
2016-05-12 22:27 sandeepkr has quit [Ping timeout: 260 seconds]
2016-05-12 22:40 sandeepkr_ has quit [Ping timeout: 246 seconds]
2016-05-12 22:40 sandeepkr_ has joined #qi-hardware
2016-05-12 23:12 doomlord_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
2016-05-12 23:48 jwhitmore has joined #qi-hardware
2016-05-12 23:55 fengling has joined #qi-hardware
2016-05-12 23:59 fengling has quit [Ping timeout: 240 seconds]