Re: Trivial program size inflation

[RVP <rvp%SDF.ORG@localhost>]

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