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

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

Thoughts?

-- 
Ed Schouten <ed_at_80386.nl>