-ffunction-sections, -fdata-sections and -Wl,--gc-sections
Ed Schouten
ed at 80386.nl
Tue Sep 17 21:45:20 UTC 2013
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>
More information about the freebsd-current
mailing list