Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections

On 16 Sep 2013, at 07:52, Dimitry Andric <dim_at_freebsd.org> wrote:

> On Sep 16, 2013, at 03:08, Adrian Chadd <adrian_at_freebsd.org> wrote:
>>> The results are interesting. On amd64:
>>> 
>>> - devd suddenly becomes 500 KB in size, instead of a megabyte,
>>> - init's size drops from 900 KB to 600 KB,
>>> - clang becomes a megabyte smaller.
>>> 
>> 
>> .. so, I'd like to know specific information as to why these three are now
>> smaller. So what's going on?
> 
> 
> This is simply unreferenced code and data being eliminated.  It is quite
> normal for libraries (libc, the LLVM libs, etc) to contain functions
> that aren't called by the program you are linking.  However, any .o file
> with multiple functions in it will be linked in as a whole, even if just
> one of the functions is called.
> 
> I really think functions and data should always be separately "packaged"
> in object files, but for some reason this has never been the default for
> GNU tools, and everybody has apparently copied the behavior. :-)

Apple's ld, lld, and MCLinker all prefer to use a finer-grained model (atoms or fragments) than segments, and so are intended to do this sort of thing by default.  This isn't an issue for dlsym(), as long as the functions that you may wish to resolve using dlsym() are explicitly marked (typically by including them in the version script) as not being eligible for deletion - only functions and data reachable from the public entry points should be retained.  Of course, if you're building a shared library and there is unreachable code or data, you probably have a bug...

Even in the shared library case, it's useful as it allows the linker to rearrange functions and data to perform optimisations to minimise PLT usage and improve cache and TLB usage by keeping functions that call each other together and data with the functions that use it (profiling can also help here, to prioritise hot functions).  

David