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

On Sun, Sep 15, 2013 at 2:24 PM, Ed Schouten <ed_at_80386.nl> wrote:

> Hi all,
>
> Today I did a tiny experiment and I am not entirely sure what to do.
> Throw away the patch or eventually push it into the tree.
>
> GCC and Clang support the -ffunction-sections and -fdata-sections
> flags. Essentially, these flags force the compiler to put every
> function and variable in its own section. Though this will blow up the
> size of the .o files a lot, it has a nice advantage. In combination
> with ld's --gc-sections flag, it can garbage collect functions and
> variables during the linking phase more accurately, thereby reducing
> the size of the resulting binary. This will of course not work for
> binaries where you want to use dlsym(), so this would only be safely
> usable in cases where you want to do static linking.
>
> I've written a tiny patch for share/mk, crunchgen and /rescue, to set
> these flags, only for .o files that are used for static linking (e.g.
> for .a files) and when linking statically linked executables.
>
> http://80386.nl/pub/gc-sections.txt
>
> 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.
>
> There is a downside, though. The total size of the system becomes 8 MB
> larger, because the .a files in /usr/lib are a bit bigger than before.
> Still, I think that this can be justified:
>
> - Systems short on disk-space are typically not used for software
> development. As /usr/include and /usr/lib/*.a together already account
> for ~30% of the disk space used, these files will likely be removed on
> a disk-space constrained system anyway.
>

I can confirm that at least one vendor who is constrained on the size of
the root partition does not install /usr/include or any *.a files.  On
shipping hardware.  We do use the hardware for developer builds where we do
need include files (though not .a files as we only use shared libraries).


> - init and devd are so fundamental that they will likely be installed
> on basically any embedded FreeBSD system. Reducing the size of these
> binaries makes sense.
> - It could also reduce the size of statically linked binaries outside
> of the base system, depending on base libraries.
>
> What I also like about this, is that at least for the base system, it
> will become less important to spread out functions in libraries over
> separate source files, in an attempt to reduce the size of the
> resulting binary. We may now leave functions that are related to each
> other in the same source file, thus improving readability.
>

Would it be possible to enable this only for devd, init, and clang
binaries?  Or is it a matter of enabling it for library builds that are
linked statically with the mentioned binaries?  Could init/devd be made
smaller by finding out which functions they do/don't use and separating
those into separate .c files?

Thanks,
matthew