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

[dsimcha]

Indeed, a couple small programs I wrote today behave erratically 
w/ gc-sections.  This only seems to occur on DMD, but I'm not 
sure if this is a bug in DMD or if differences in library build 
configurations between compilers (these are workarounds for bugs 
in GDC and LDC) explain it.

On Wednesday, 21 December 2011 at 04:15:21 UTC, Artur Skawina 
wrote:
> 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