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