https://issues.dlang.org/show_bug.cgi?id=879
--- Comment #18 from Martin Nowak <[email protected]> --- (In reply to David Nadlinger from comment #17) > 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. Right, gc-sections doesn't care about visibility, but the ModuleInfos are not emitted to individual sections (.rodata or .text) so they won't get removed unless they are the only symbols in .rodata/.text. > (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? Yes, object files from an archive. It's probably the same for normal objects. With --gc-sections the ld.gold linker seems to only copy sections that contain referenced symbols. I can also reference .minfo_beg/.minfo/.minfo_end in each ctor, but for some reason the order for the output sections isn't preserved. > On Linux x86_64, our static release-mode binaries > are on average 1/4 the size of DMD's for small programs now Interesting, dmd uses a section per function by default, but for unknown reasons --gc-sections doesn't have a huge effect. https://github.com/D-Programming-Language/dmd/pull/3597#issuecomment-44671223 I'd like to give the linker as good information as possible. For example when a functions isn't used the linker should strip the associated EH data. Likewise ModuleInfo is needed only when any data or function of a module end up in a DSO. --
