[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130408154355.GP20323@brightrain.aerifal.cx>
Date: Mon, 8 Apr 2013 11:43:55 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Building libc separately from libm,librt,libpthread and
others
On Mon, Apr 08, 2013 at 10:43:25AM +0300, Timerlan Moldobaev wrote:
> John , thank you for pointing out that size() is used in the comparison
> table, somehow oversaw that.
> BTW, out of curiosity where does the extra size come from ? Some elf
> specific format data ?
A .o file contains a lot of information beyond code: it has to have
all the symbols defined or referenced in the file, as well as the
relocations for both symbolic references and addresses of objects
defined in the same file. Even with a very efficient object format
like the old a.out format, this additional data is likely to be nearly
as large as or larger than an object file containing a single function
or just a few small functions. ELF's storage of this additional data
is much more general/flexible, but also much less efficient; often
it's several times as big as the code. In a worst case, it's hundreds
of times larger (e.g. if the code is just a single "ret" instruction).
The reason I use size(1) rather than file size to measure static
library size is twofold:
1. The size of the actual code and data, not the size of the .o files
in the .a file, is what actually ends up in your final binary.
Actually if you don't strip the binary, some of the additional
information (symbols, etc.) will end up in the final binary too, but
it's proportionally much smaller since it's just one set of tables for
the whole binary rather than one set for each translation unit.
2. Any metric based on .a file size rather than size(1) will "reward"
implementations that are poorly-factored and thus yield larger static
binaries. The easiest way to make your .a file look smaller is to
merge lots of source files together. This indeed reduces the size of
the .a file, but the cost is that programs which use one function from
the .a file will be forced to pull in several other functions they may
not need.
Due to misc. costs of having lots of .o files (build time for musl
itself, excess file size of the .a file, etc.) I've actually merged
some functions into common files. The usual criteria for such merging
are that the functions each be tiny/trivial and not likely to be
useful in tiny applications.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
