https://issues.dlang.org/show_bug.cgi?id=879
--- Comment #17 from David Nadlinger <[email protected]> --- (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. --
