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

Hi Matthew,

2013/9/16 Matthew Fleming <mdf_at_freebsd.org>:
> 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?

For it to have effect, it has to be enabled for both the libraries and
the binaries. The libraries need to be built with
-f{data,function}-sections. The binaries can also be built with those
flags, but it is actually more important to link with --gc-sections.

> Could init/devd be made smaller by
> finding out which functions they do/don't use and separating those into
> separate .c files?

Also trying to answer Tim and Adrian's questions at the same time.
I've just taken a look at init and devd to see why the difference in
size is so big:

init seems to pull in the following things:

- Sun RPC,
- XDR,
- YP,
- res_*,
- All of the jemalloc profiling/stats code,
- Some widechar functions,
- malloc-related utility functions that are not used (posix_memalign,
aligned_alloc),
- Some stdio bloat,
- All sorts of termios tc* functions.

devd seems to pull in these:

- A very big pile of C++ symbols, as libc++ places many functions in a
single file.
- jemalloc profiling/stats again,
- A big pile of pthread,
- Maybe *_l() functions, which are of course rarely used.

Honestly, I think we can assume we'll never reach the point where all
the components listed above will properly have all functions
partitioned over separate compilation units.

I suspect that it would make a lot of sense to at least enable these
build flags for our core libraries (libc, libc++, libpthread,
libcompiler_rt, libcxxrt, etc). We could also enable it on
INTERNALLIBs (libraries that are not installed into /usr/lib), as for
these libraries, it would of course not come at any cost.

Would that sound okay?

-- 
Ed Schouten <ed_at_80386.nl>