Re: Trivial program size inflation

[Taylor R Campbell <campbell+netbsd-tech-userlevel%mumble.net@localhost>]

> Date: Fri, 30 Jun 2023 13:37:10 -0400 (EDT)
> From: Mouse <mouse%Rodents-Montreal.ORG@localhost>
> 
> sparc, my mutant 1.4T:
> 
> text    data    bss     dec     hex     filename
> 12616   124     288     13028   32e4    main
> 
> amd64, my mutant 5.2:
> 
>    text	   data	    bss	    dec	    hex	filename
>  152613	   4416	  16792	 173821	  2a6fd	main
> 
> amd64, 9.0_STABLE (ftp.n.o):
> 
>    text    data     bss     dec     hex filename
>  562318   29064 2176416 2767798  2a3bb6 main
> 
> 12K to do nothing is bad enough (I'm going to be looking at why it's
> that big).  149K is even more disturbing (I'll be looking at that too).
> But over half a meg of text and two megs of BSS?  To do nothing?
> Surely something is wrong somewhere.

I just touched up libbsdmalloc in HEAD so that you can use it as a
replacement for jemalloc in libc by statically linking with
-lbsdmalloc:

$ cat main.c
int main(void) { return 0; }
$ cc -o main main.c -static -Wl,--whole-archive -lbsdmalloc -Wl,--no-whole-archive -Wl,-Map=main.map
$ size main
   text    data     bss     dec     hex filename
  35680    3312    3472   42464    a5e0 main

The --whole-archive dance is unnecessary if your program calls malloc,
calloc, realloc, aligned_alloc, posix_memalign, or free.  If the size
still turns up unreasonably large, you can examine main.map to see
what's pulling in what.

Other low-hanging fruit I see would be to split getenv out of the
other environment variable operations, to get rid of locking and
rbtree stuff.  But it's diminishing returns at this point -- not clear
the attached patchset/diff is worth committing.  Gets me down to this:

   text    data     bss     dec     hex filename
  30744    3280    3376   37400    9218 main

After that, maybe we could find a substitute for the syslog_ss stuff
in stack-protector -- but that's probably not worth the trouble, for
what is maybe another few kilobytes or so.