<div><div dir="auto">Suppose i write</div><div dir="auto"><br></div><div dir="auto">// foo.cpp</div><div dir="auto">__attribute__((section(“foo”))) int x;</div><div dir="auto"><br></div><div dir="auto">// bar.cpp</div><div dir="auto">__attribute__((section(“foo”))) int y;</div><div dir="auto"><br></div><div dir="auto">And i compile and link these two object files together using lld.  What assumptions can I make regarding alignment/padding between the two symbols? </div><div dir="auto"><br></div><div dir="auto">I’m comfortable getting an answer by reading the source, but that won’t tell if any properties i discover  are guaranteed or just happenstance.</div><div dir="auto"><br></div><div dir="auto">Are all of the following guaranteed ?</div><div dir="auto">A) relative order of symbols within a TU is not modified by the linker </div><div dir="auto">B) No padding is inserted by the linker between symbols in a TU aside from that which was already inserted by the compiler/assembler</div><div dir="auto">C) When merging section A from inputs B and C, the minimal amount of padding necessary so that the first symbol from C is properly aligned is inserted.</div><div dir="auto"><br></div><div dir="auto">I think(?) these conditions would be sufficient to guarantee, for example, that I could implement my own .ctor / @init_array logic using only the front end.</div><div dir="auto"><br></div><div dir="auto">And are there any subtle interactions here with -fdata-sections or behavioral differences across COFF/ELF/MachO?</div><div dir="auto"><br></div><div dir="auto">Is there anyone who can provide some insight on this?</div>
</div>