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
