[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

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

--- Comment #18 from Martin Nowak <code at dawg.eu> ---
(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.

--