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

[Sean Kelly]

http://d.puremagic.com/issues/show_bug.cgi?id=879

On Dec 21, 2011, at 2:24 PM, dsimcha wrote:

> 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
> 
>