> Date: Fri, 30 Jun 2023 13:37:10 -0400 (EDT)
> From: Mouse <mo...@rodents-montreal.org>
>
> 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.
