[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #17 from David Nadlinger <code at klickverbot.at> ---
(In reply to Martin Nowak from comment #15)
> ModuleInfos are exported global symbols, so the linker should not remove
> them.

I was under the impression that --gc-sections indeed does this when linking an
executable. Default visibility on its own is not enough to keep a symbol (and
thus its section) alive, unless it is required to resolve an undefined symbol
from a linked shared object. Maybe we have a different understanding of what an
"exported symbol" is, though.

(In reply to Martin Nowak from comment #16)
> Another problem that I have is that ld.gold with --gc-sections doesn't copy the .minfo_beg/.minfo_end sections from an archive object, so it breaks the section brackets even when all .minfo* sections are pinned.

What precisely do you refer to as "archive object"? An object file pulled in
from a static library? As we discussed a while ago, for LDC I currently emit
one unique global ctor per object file (as we emit one section per text/data
symbol like -ffunction-sections, this is not quite as bad as it maybe would be
for dmd -lib, even though still a bit wasteful). As .ctors are roots for the
linker's live section graph, I can conveniently pin the bracketing symbols as
well as the ModuleInfo reference itself that way.

The whole "design" was purely a workaround for LLVM bugs/limitations, but it
lead to LDC passing the test suite [*] using both ld.bfd and ld.gold without
too much effort. As mentioned above, LDC currently generates quite a bit of
cruft in the executable due to unneeded symbols in .minfo_beg/.minfo_end and
all the duplicate global ctors, but it's still better than not being able to
use --gc-sections at all. On Linux x86_64, our static release-mode binaries are
on average 1/4 the size of DMD's for small programs now (Git master vs. Git
master, which isn't entirely fair because we are still on 2.065, of course).


[*] Except for the module conflict check in druntime being broken due to copy
relocations.

--