tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Trivial program size inflation



On Mon, 3 Jul 2023, Mouse wrote:

Looking at the resulting null.map, I see, among many other lines,

/usr/lib/libc.a(jemalloc.o)   /usr/lib/libc.a(tls.o) (calloc)

which makes sense: if nothing in null.o, crt0.o, crti.o, or crtbeginT.o
refers to anything in the libgnumalloc file containing calloc, nothing
will have brought it in from libgnumalloc.  Then, when libc refers to
it internally, -lgnumalloc is past and thus unavailable for resolving
it, so it comes from the default malloc in libc.

So I tried, instead,

% ld -Map=null.map -dc -dp -e _start -static -o null /usr/lib/crt0.o /usr/lib/crti.o /usr/lib/crtbeginT.o null.o --whole-archive -lgnumalloc --no-whole-archive -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o

to force all of libgnumalloc to be brought in.  Sure enough, this time,
"je" does not appear in the link map, and the executable is
significantly smaller.


Yes, except this doesn't work (as expected) with bsdmalloc because it
doesn't implement calloc(), so the linker will get that (and all the je_*
stuff now) from libc.a again. :)

Somebody should maybe add calloc() to bsdmalloc.

-RVP


Home | Main Index | Thread Index | Old Index