<div><div dir="auto">Thanks for your answers!  To clarify about .ctor / init_array, I didn’t mean necessarily those exact sections, but rather something like it.  Basically, i want to write some data into a section from multiple TUs, and then at runtime parse the ELF/MachO/COFF image via its load address in memory to find my section and iterate its contents.  In the simple case the contents will just be a list of function pointers, but in a more complicated case i can imagine some size-prefixed variable length records.  </div><div dir="auto"><br></div><div dir="auto">So I mostly just wanted some confidence that the linker is not allowed to change the final output section in such a way as to break this kind of thing.  It sounds like I’m safe though (for ELF at least).</div></div><div dir="auto"><br></div><div dir="auto">Thank you!</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 25, 2020 at 9:39 AM Fangrui Song <<a href="mailto:maskray@google.com">maskray@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2020-07-24, Zachary Turner via llvm-dev wrote:<br>
>Suppose i write<br>
><br>
>// foo.cpp<br>
>__attribute__((section(“foo”))) int x;<br>
><br>
>// bar.cpp<br>
>__attribute__((section(“foo”))) int y;<br>
><br>
>And i compile and link these two object files together using lld.  What<br>
>assumptions can I make regarding alignment/padding between the two symbols?<br>
><br>
>I’m comfortable getting an answer by reading the source, but that won’t<br>
>tell if any properties i discover  are guaranteed or just happenstance.<br>
<br>
I am only relatively confident about ELF semantics.<br>
<br>
The ELF specification defines says<br>
(<a href="http://www.sco.com/developers/gabi/latest/ch4.sheader.html" rel="noreferrer" target="_blank">http://www.sco.com/developers/gabi/latest/ch4.sheader.html</a>) that:<br>
<br>
   ... When not otherwise constrained, sections should be emitted in input order.<br>
<br>
For object files this is clear. For archives without --start-group this<br>
can be considered clear as well. For archives with --start-group (LLD<br>
implicitly adds --start-group for every archive)) the input order is the<br>
time point its member is fetched.<br>
<br>
    ld.lld ... foo.a bar.o   # bar.o(foo) may come before foo.a(foo.o(foo))<br>
<br>
>Are all of the following guaranteed ?<br>
>A) relative order of symbols within a TU is not modified by the linker<br>
<br>
If you have more symbols defined relative to foo, i.e.<br>
<br>
   __attribute__((section('foo"))) int x;<br>
   __attribute__((section("foo"))) int z;<br>
<br>
Yes, the order of x and z in the input section is their relative order<br>
in the output section. The input section is handled as a whole. A linker<br>
cannot reorder content within an input section.<br>
<br>
>B) No padding is inserted by the linker between symbols in a TU aside from<br>
>that which was already inserted by the compiler/assembler<br>
<br>
Yes. The ELF spec says "...  it must honor the alignment constraints of<br>
the input sections (asserted by the sh_addralign field)"<br>
<br>
>C) When merging section A from inputs B and C, the minimal amount of<br>
>padding necessary so that the first symbol from C is properly aligned is<br>
>inserted.<br>
<br>
Yes (unless you use linker scripts: foo : { foo.o(foo) BYTE(0) bar.o(foo) })<br>
<br>
>I think(?) these conditions would be sufficient to guarantee, for example,<br>
>that I could implement my own .ctor / @init_array logic using only the<br>
>front end.<br>
<br>
You can implement .ctor, which is of type SHT_PROGBITS.<br>
<br>
For .init_array, GCC __attribute__((section(name))) cannot set the<br>
section type to SHT_INIT_ARRAY. GNU as will set SHT_PROGBITS anyway but<br>
also emit a warning: Warning: setting incorrect section attributes for .init_array<br>
<br>
You can use module level inline asm (.pushsection ... .popsection), though...<br>
<br>
>And are there any subtle interactions here with -fdata-sections or<br>
>behavioral differences across COFF/ELF/MachO?<br>
><br>
>Is there anyone who can provide some insight on this?<br>
</blockquote></div></div>