kyak changed the topic of #qi-hardware to: Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben/atusb 802.15.4 wireless, anelok and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
MistahDarcy has quit [Ping timeout: 250 seconds]
MistahDarcy has joined #qi-hardware
arossdotme has quit [Ping timeout: 252 seconds]
MistahDarcy has quit [Ping timeout: 260 seconds]
MistahDarcy has joined #qi-hardware
archang has joined #qi-hardware
sandeepkr has quit [Read error: Connection reset by peer]
sandeepkr has joined #qi-hardware
<whitequark> DocScrutinizer51: set_transient_window
archang has quit [Ping timeout: 260 seconds]
arossdotme has joined #qi-hardware
fengling has joined #qi-hardware
sandeepkr has quit [Read error: Connection reset by peer]
sandeepkr has joined #qi-hardware
sandeepkr has quit [Read error: Connection reset by peer]
xiangfu has joined #qi-hardware
sb0 has quit [Quit: Leaving]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
xiangfu has quit [Ping timeout: 276 seconds]
sandeepkr has joined #qi-hardware
xiangfu has joined #qi-hardware
fengling has quit [Ping timeout: 240 seconds]
sandeepkr has quit [Ping timeout: 276 seconds]
fengling has joined #qi-hardware
sandeepkr has joined #qi-hardware
sandeepkr has quit [Read error: No route to host]
sandeepkr has joined #qi-hardware
xiangfu has quit [Ping timeout: 276 seconds]
xiangfu has joined #qi-hardware
pcercuei has joined #qi-hardware
<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?
<whitequark> as far as I know, the array entry size does not matter, only whether the members go in the right places
<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
<whitequark> there's no reason the linker should
<larsc> I have an array of pointers
<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)
<larsc> if I have only one entry it's simply aligned to the pointer size
<larsc> but if I have more it is aligned at a larger size
<whitequark> how do you determine how is it aligned?
<larsc> up to 4 times the pointer size
<whitequark> nm?
<larsc> yes
<whitequark> I think this is a compiler-specific optimization
<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
<larsc> and what I'm seeing right now is that there are sometimes gaps
<larsc> nothing that can't be handled, but still not so nice
<whitequark> ohh
<larsc> or do you think this is a bad idea in general?
<whitequark> yes, to do this you need to explicitly call out the alignment on the global
<whitequark> no, it's a perfectluy fine idea
<whitequark> libc does this
<whitequark> for .init/.fini
<whitequark> just use __attributes__((align(sizeof(void*))))
<whitequark> align(...),section(".whatever")
<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
<whitequark> exactly describes your use case
sb0 has joined #qi-hardware
<larsc> ok, thanks, that's quite helpful
<larsc> ok, works perfectly, with explicit alignment the gaps are gone
<larsc> Do you know how portable such an approach is? This is for libsigrok
<whitequark> this will work on gcc and clang
<whitequark> well
<whitequark> the code to put it into a section is just as portable as the alignment attribute
<whitequark> so this specific part creates no new problems
<larsc> I mean the approach of using sections as arrays, do you can think of any platform where it will break
<whitequark> msvc
<whitequark> you'll have to use __declspec(allocate)
<pcercuei> < whitequark> just use __attributes__((align(sizeof(void*))))
<pcercuei> not portable
<pcercuei> dammit, you just said it
<pcercuei> I should read to the end :)
<larsc> with it's lack of support for current C standards msvc is probably not a target anyway
<larsc> thanks
<wpwrak> everything seems to converge to gcc anyway
jwhitmore has joined #qi-hardware
<whitequark> I don't see anything wrong with it
<larsc> ok, thanks.
xiangfu has quit [Ping timeout: 240 seconds]
xiangfu has joined #qi-hardware
<pcercuei> larsc, GCC adds the __start_$(section) / __stop_$(section) symbols automatically?
sb0 has quit [Quit: Leaving]
<larsc> yes
<pcercuei> nice
<whitequark> does it?
<whitequark> I'm pretty sure it doesn't, that's the default glibc linker script
<whitequark> you might want to check that on non-glibc systems
fengling has quit [Quit: WeeChat 1.4]
fengling has joined #qi-hardware
<DocScrutinizer05> to avoid any gaps, wrap the whole data section up into one hige struct
<DocScrutinizer05> huge
<DocScrutinizer05> so it becomes one entity without gaps in between
<wpwrak> whitequark: i'd also be surprised if the compiler did that. at least i never encountered such
<wpwrak> DocScrutinizer05: the whole idea is to be able to distribute those things :)
<whitequark> DocScrutinizer05: doesn't work if the whole point is to assemble it from multiple files
<DocScrutinizer05> rrright
<wpwrak> and it's a very well-established practice to do this. e.g., the linux kernel heavily makes use of this
<DocScrutinizer05> but then you need to depend on the linker (or compiler *maybe*) since you can't coordinate stuff across files
<larsc> well, it's definitly not the compiler because the compiler can't do that
<DocScrutinizer05> wpwrak: this?
<DocScrutinizer05> larsc: that's what I think too
<whitequark> yes. you need to depend on the linker.
<whitequark> if you don't provide your own linker script, the default linker script does something like this
<wpwrak> DocScrutinizer05: this = special sections to collect lists of items
<whitequark> alternatively, you can go the crtbegin.o/crtend.o way
<DocScrutinizer05> aaah
<whitequark> where you put a sentinel into a begin.o file and an end.o file
<whitequark> since linkers assemble sections in the order that they appear on the command line
<whitequark> this is somewhat more portable than depending on specific glibc linker script
<whitequark> larsc: I think __attribute__((constructor)) will allow you to do the same without the mess of working with sections directly
<whitequark> i.e. it will work on all practical ELF platforms regardless of libc
<whitequark> oh and __attribute__((constructor)) also works on OS X
<whitequark> soo... i think you're covered, really
fengling has quit [Ping timeout: 240 seconds]
<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.
fengling has joined #qi-hardware
<wpwrak> whitequark: but attribute((constructor)) means that it gets executed, no ? so that wouldn't work in lars' case
<larsc> hm I don't like constructor that much
<whitequark> it will get executed and register itself in some global linked list or w/e
<larsc> well you can have a function that adds things to a linked list or whatever
<whitequark> exactly
<wpwrak> (at least no without a detour)
<larsc> but I don't like that
<whitequark> it's cleaner because you don't rely on __start and otherwise it's the same thing
<larsc> at least as long as long as the section approach works
<whitequark> global constructors are generally evil but if the only thing you need is to set a single pointer
<whitequark> theyre ok
<larsc> it's hard to find actual documentation on the __start __stop symbols
<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
<whitequark> this will break on OS X.
<whitequark> since OS X has no linker scripts
<whitequark> but, OS X supports constructor attribute
<whitequark> (anything that supports C++ properly does)
<larsc> hm
<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"
<whitequark> larsc: yes. either of those works. or just use constructor.
<larsc> wpwrak: yes, it's terrible
<larsc> or is it?
<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
<wpwrak> (note: just spotted this, so i don't know how well it works in practice)
<larsc> hm
<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
<whitequark> wpwrak: os x has hardcoded start/end symbols
<whitequark> theyre just... different
<whitequark> you could use constructors and work anywhere c++ and gcc-like attributes work, which is a lot of places
<whitequark> and never think about that shit again
<larsc> wpwrak: it looks as if you put INSERT AFTER $section into your custom linker script it wil also only augment the default
<larsc> whitequark: but micro optimizations!
<whitequark> what
<whitequark> have you *seen* how much shit the dynamic linker does
fengling has quit [Ping timeout: 240 seconds]
<larsc> no
<larsc> luckily I never had to
<DocScrutinizer05> hehe
<whitequark> you can start by stracing it
<whitequark> anything dynamically linked
<DocScrutinizer05> get towels for the bleeding eyes?
<whitequark> transfusions
sb0 has joined #qi-hardware
xiangfu has quit [Ping timeout: 276 seconds]
xiangfu has joined #qi-hardware
fengling has joined #qi-hardware
fengling has quit [Ping timeout: 240 seconds]
bzb has joined #qi-hardware
xiangfu has quit [Ping timeout: 244 seconds]
xiangfu has joined #qi-hardware
bzb has quit [Quit: Leaving]
doomlord_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
doomlord_ has joined #qi-hardware
fengling has joined #qi-hardware
fengling has quit [Ping timeout: 240 seconds]
sb0 has quit [Read error: Connection reset by peer]
doomlord_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
xiangfu has quit [Remote host closed the connection]
doomlord_ has joined #qi-hardware
sb0 has joined #qi-hardware
doomlord_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
doomlord_ has joined #qi-hardware
fengling has joined #qi-hardware
fengling has quit [Ping timeout: 240 seconds]
jwhitmore has quit [Ping timeout: 260 seconds]
pcercuei has quit [Quit: leaving]
<DocScrutinizer05> http://www.experten-arbeit-stärken.de/
wildlander has joined #qi-hardware
jwhitmore has joined #qi-hardware
fengling has joined #qi-hardware
pcercuei has joined #qi-hardware
fengling has quit [Ping timeout: 240 seconds]
sandeepkr has quit [Ping timeout: 265 seconds]
sandeepkr has joined #qi-hardware
rjeffries has joined #qi-hardware
fengling has joined #qi-hardware
fengling has quit [Ping timeout: 240 seconds]
rjeffries has quit [Ping timeout: 246 seconds]
jwhitmore has quit [Ping timeout: 246 seconds]
pcercuei has quit [Quit: leaving]
wildlander has quit [Quit: Saliendo]
fengling has joined #qi-hardware
fengling has quit [Ping timeout: 240 seconds]
sandeepkr_ has joined #qi-hardware
sandeepkr has quit [Ping timeout: 260 seconds]
sandeepkr_ has quit [Ping timeout: 246 seconds]
sandeepkr_ has joined #qi-hardware
doomlord_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jwhitmore has joined #qi-hardware
fengling has joined #qi-hardware
fengling has quit [Ping timeout: 240 seconds]