| 00:44.03 | *** join/#qi-hardware MistahDarcy (~crash@fsf/member/MistahDarcy) |
| 01:31.06 | *** join/#qi-hardware MistahDarcy (~crash@fsf/member/MistahDarcy) |
| 01:56.17 | *** join/#qi-hardware archang (~archang@111.198.29.53) |
| 01:59.44 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 02:05.02 | whitequark | DocScrutinizer51: set_transient_window |
| 02:34.11 | *** join/#qi-hardware arossdotme (~zxy@host-78-151-194-102.as13285.net) |
| 02:57.50 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 03:02.06 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 03:03.37 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 04:00.02 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 05:05.01 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 05:14.40 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 06:11.25 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 06:28.21 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 06:44.06 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 07:00.50 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 08:27.00 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 08:28.05 | 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? |
| 08:30.33 | whitequark | as far as I know, the array entry size does not matter, only whether the members go in the right places |
| 08:31.02 | 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 |
| 08:31.11 | whitequark | there's no reason the linker should |
| 08:31.37 | larsc | I have an array of pointers |
| 08:31.43 | 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) |
| 08:31.53 | larsc | if I have only one entry it's simply aligned to the pointer size |
| 08:32.07 | larsc | but if I have more it is aligned at a larger size |
| 08:32.14 | whitequark | how do you determine how is it aligned? |
| 08:32.15 | larsc | up to 4 times the pointer size |
| 08:32.16 | whitequark | nm? |
| 08:32.22 | larsc | yes |
| 08:32.44 | whitequark | I think this is a compiler-specific optimization |
| 08:33.21 | 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 |
| 08:33.38 | larsc | and what I'm seeing right now is that there are sometimes gaps |
| 08:33.50 | larsc | nothing that can't be handled, but still not so nice |
| 08:33.51 | whitequark | ohh |
| 08:34.00 | larsc | or do you think this is a bad idea in general? |
| 08:34.03 | whitequark | yes, to do this you need to explicitly call out the alignment on the global |
| 08:34.07 | whitequark | no, it's a perfectluy fine idea |
| 08:34.09 | whitequark | libc does this |
| 08:34.12 | whitequark | for .init/.fini |
| 08:34.23 | whitequark | just use __attributes__((align(sizeof(void*)))) |
| 08:34.36 | whitequark | align(...),section(".whatever") |
| 08:35.18 | whitequark | http://llvm.org/docs/LangRef.html#global-variables |
| 08:35.24 | 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 |
| 08:35.31 | whitequark | exactly describes your use case |
| 08:35.31 | *** join/#qi-hardware sb0 (~lekernel@59.152.213.90) |
| 08:36.07 | larsc | ok, thanks, that's quite helpful |
| 08:41.19 | larsc | ok, works perfectly, with explicit alignment the gaps are gone |
| 08:43.49 | larsc | Do you know how portable such an approach is? This is for libsigrok |
| 08:52.10 | whitequark | this will work on gcc and clang |
| 08:52.24 | whitequark | well |
| 08:52.33 | whitequark | the code to put it into a section is just as portable as the alignment attribute |
| 08:52.41 | whitequark | so this specific part creates no new problems |
| 08:54.37 | larsc | I mean the approach of using sections as arrays, do you can think of any platform where it will break |
| 08:55.21 | whitequark | msvc |
| 08:55.50 | whitequark | you'll have to use __declspec(allocate) |
| 08:57.12 | pcercuei | < whitequark> just use __attributes__((align(sizeof(void*)))) |
| 08:57.17 | pcercuei | not portable |
| 08:57.59 | pcercuei | dammit, you just said it |
| 08:58.03 | pcercuei | I should read to the end :) |
| 08:59.27 | larsc | with it's lack of support for current C standards msvc is probably not a target anyway |
| 08:59.30 | larsc | thanks |
| 09:02.13 | wpwrak | everything seems to converge to gcc anyway |
| 09:06.25 | *** join/#qi-hardware jwhitmore (~jwhitmore@91.123.229.11) |
| 09:14.01 | larsc | whitequark: does this look ok to you? https://github.com/analogdevicesinc/libsigrok/commit/0a66432e5cd34bf8b6d9d144b0a7ca182b290816#diff-88d499a1a7ecc6d02d08a96525e502e5 |
| 09:14.04 | larsc | and https://github.com/analogdevicesinc/libsigrok/commit/0a66432e5cd34bf8b6d9d144b0a7ca182b290816#diff-7af547b52769371de74af0bfca268a62 |
| 09:21.51 | whitequark | I don't see anything wrong with it |
| 09:22.04 | larsc | ok, thanks. |
| 09:36.58 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 10:07.23 | pcercuei | larsc, GCC adds the __start_$(section) / __stop_$(section) symbols automatically? |
| 10:19.12 | larsc | yes |
| 10:21.35 | pcercuei | nice |
| 10:28.23 | whitequark | does it? |
| 10:28.33 | whitequark | I'm pretty sure it doesn't, that's the default glibc linker script |
| 10:28.39 | whitequark | you might want to check that on non-glibc systems |
| 10:32.56 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 10:32.57 | DocScrutinizer05 | to avoid any gaps, wrap the whole data section up into one hige struct |
| 10:33.01 | DocScrutinizer05 | huge |
| 10:33.37 | DocScrutinizer05 | so it becomes one entity without gaps in between |
| 10:35.18 | wpwrak | whitequark: i'd also be surprised if the compiler did that. at least i never encountered such |
| 10:35.35 | wpwrak | DocScrutinizer05: the whole idea is to be able to distribute those things :) |
| 10:35.49 | whitequark | DocScrutinizer05: doesn't work if the whole point is to assemble it from multiple files |
| 10:36.00 | DocScrutinizer05 | rrright |
| 10:36.15 | wpwrak | and it's a very well-established practice to do this. e.g., the linux kernel heavily makes use of this |
| 10:36.38 | DocScrutinizer05 | but then you need to depend on the linker (or compiler *maybe*) since you can't coordinate stuff across files |
| 10:36.55 | larsc | well, it's definitly not the compiler because the compiler can't do that |
| 10:36.56 | DocScrutinizer05 | wpwrak: this? |
| 10:37.19 | DocScrutinizer05 | larsc: that's what I think too |
| 10:37.22 | whitequark | yes. you need to depend on the linker. |
| 10:37.41 | whitequark | if you don't provide your own linker script, the default linker script does something like this |
| 10:37.48 | wpwrak | DocScrutinizer05: this = special sections to collect lists of items |
| 10:37.49 | whitequark | alternatively, you can go the crtbegin.o/crtend.o way |
| 10:37.56 | DocScrutinizer05 | aaah |
| 10:38.07 | whitequark | where you put a sentinel into a begin.o file and an end.o file |
| 10:38.19 | whitequark | since linkers assemble sections in the order that they appear on the command line |
| 10:38.35 | whitequark | this is somewhat more portable than depending on specific glibc linker script |
| 10:39.48 | whitequark | larsc: I think __attribute__((constructor)) will allow you to do the same without the mess of working with sections directly |
| 10:40.04 | whitequark | i.e. it will work on all practical ELF platforms regardless of libc |
| 10:41.05 | whitequark | oh and __attribute__((constructor)) also works on OS X |
| 10:41.12 | whitequark | soo... i think you're covered, really |
| 10:42.58 | 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. |
| 10:43.53 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 10:45.26 | larsc | hm I don't like constructor that much |
| 10:45.26 | wpwrak | whitequark: but attribute((constructor)) means that it gets executed, no ? so that wouldn't work in lars' case |
| 10:45.45 | whitequark | it will get executed and register itself in some global linked list or w/e |
| 10:45.46 | larsc | well you can have a function that adds things to a linked list or whatever |
| 10:45.51 | whitequark | exactly |
| 10:45.52 | wpwrak | (at least no without a detour) |
| 10:46.05 | larsc | but I don't like that |
| 10:46.12 | whitequark | it's cleaner because you don't rely on __start and otherwise it's the same thing |
| 10:46.17 | larsc | at least as long as long as the section approach works |
| 10:46.29 | whitequark | global constructors are generally evil but if the only thing you need is to set a single pointer |
| 10:46.32 | whitequark | theyre ok |
| 10:47.57 | larsc | it's hard to find actual documentation on the __start __stop symbols |
| 10:48.35 | 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 |
| 10:49.27 | whitequark | this will break on OS X. |
| 10:49.31 | whitequark | since OS X has no linker scripts |
| 10:49.37 | whitequark | but, OS X supports constructor attribute |
| 10:49.50 | whitequark | (anything that supports C++ properly does) |
| 10:52.54 | larsc | hm |
| 10:52.56 | larsc | http://stackoverflow.com/questions/17669593/how-to-get-a-pointer-to-a-binary-section-in-mac-os-x |
| 10:53.21 | 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" |
| 10:54.05 | whitequark | larsc: yes. either of those works. or just use constructor. |
| 11:03.11 | larsc | wpwrak: yes, it's terrible |
| 11:03.42 | larsc | or is it? |
| 11:04.32 | 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 |
| 11:05.05 | wpwrak | (note: just spotted this, so i don't know how well it works in practice) |
| 11:05.26 | larsc | hm |
| 11:05.48 | 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 |
| 11:28.33 | whitequark | wpwrak: os x has hardcoded start/end symbols |
| 11:28.38 | whitequark | theyre just... different |
| 11:28.52 | whitequark | you could use constructors and work anywhere c++ and gcc-like attributes work, which is a lot of places |
| 11:28.56 | whitequark | and never think about that shit again |
| 11:47.05 | larsc | wpwrak: it looks as if you put INSERT AFTER $section into your custom linker script it wil also only augment the default |
| 11:48.46 | larsc | whitequark: but micro optimizations! |
| 11:49.33 | whitequark | what |
| 11:49.44 | whitequark | have you *seen* how much shit the dynamic linker does |
| 11:51.14 | larsc | no |
| 11:51.29 | larsc | luckily I never had to |
| 11:52.22 | DocScrutinizer05 | hehe |
| 11:52.25 | whitequark | you can start by stracing it |
| 11:52.30 | whitequark | anything dynamically linked |
| 11:52.43 | DocScrutinizer05 | get towels for the bleeding eyes? |
| 12:00.46 | whitequark | transfusions |
| 12:32.43 | *** join/#qi-hardware sb0 (~lekernel@123202036228.ctinets.com) |
| 12:45.25 | *** join/#qi-hardware xiangfu (~xiangfu@49.4.170.106) |
| 13:39.49 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 14:11.19 | *** join/#qi-hardware bzb (~bzb@198-48-208-237.cpe.pppoe.ca) |
| 14:35.36 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 15:36.18 | *** join/#qi-hardware doomlord_ (~textual@host81-153-147-173.range81-153.btcentralplus.com) |
| 15:43.49 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 16:25.10 | *** join/#qi-hardware doomlord_ (~textual@host81-153-147-173.range81-153.btcentralplus.com) |
| 16:27.34 | *** join/#qi-hardware sb0 (~lekernel@123202036228.ctinets.com) |
| 16:35.02 | *** join/#qi-hardware doomlord_ (~textual@host81-153-147-173.range81-153.btcentralplus.com) |
| 16:44.36 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 17:39.21 | DocScrutinizer05 | http://www.experten-arbeit-stärken.de/ |
| 17:59.53 | *** join/#qi-hardware wildlander (~wild@unaffiliated/wildlander) |
| 18:46.23 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.77.239.215) |
| 18:47.45 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 18:52.28 | *** join/#qi-hardware pcercuei (~pcercuei@185.13.202.207) |
| 19:17.17 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 19:18.07 | *** join/#qi-hardware rjeffries (~rjeffries@pool-74-106-217-43.snloca.dsl-w.verizon.net) |
| 19:49.08 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 21:52.00 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 22:24.03 | *** join/#qi-hardware sandeepkr_ (~sandeep@111.235.64.4) |
| 22:40.49 | *** join/#qi-hardware sandeepkr_ (~sandeep@111.235.64.4) |
| 23:48.19 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.77.239.215) |
| 23:55.05 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |