Binary Size: function-sections, data-sections, etc.

Artur Skawina art.08.09 at gmail.com
Tue Dec 20 12:46:15 PST 2011


On 12/20/11 19:59, Trass3r wrote:
> Seems like --gc-sections _can_ have its pitfalls:
> http://blog.flameeyes.eu/2009/11/21/garbage-collecting-sections-is-not-for-production
> 
> Also I read somewhere that --gc-sections isn't always supported (no standard switch or something like that).

The scenario in that link apparently involves a hack, where a completely unused symbol
is used to communicate with another program/library (which checks for its presence with
dlsym(3)).
The linker will omit that symbol, as nothing else references it - the solution is to
simply reference it from somewhere. Or explicitly place it in a used section. Or
incrementally link in the unused symbols _after_ the gc pass. Or...

If you use such hacks you have to handle them specially; there's no way for the compiler
to magically know which unreferenced symbols are not really unused. (which is also why
this optimization isn't very useful for shared libs - every visible symbol has to be
assumed used, for obvious reasons)

The one potential problematic case i mentioned in that gdc bug mentioned above is this:
If the D runtime (most likely GC) needs to know the start/end of the data and bss
sections _and_ does it in a way that can confuse it if some unreferenced parts of these
sections disappear and/or are reordered, then turning on the section GC could uncover
this bug. From the few simple tests i ran here everything seems to work fine, but I did
not check the code to confirm there are no incorrect assumptions present.

> I personally see no reason not to use -ffunction-sections and -fdata-sections for compiling phobos though, cause a test with gdc didn't even result in a much bigger lib file, nor did it take significantly longer to compile/link.

737k -> 320k executable size reduction is a compelling argument.

> That site I linked claims though, that it does mean serious overhead even if --gc-sections is omitted then.

?

> So we have to do tests with huge codebases first.

yes.

artur


More information about the Digitalmars-d mailing list