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