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
