> Note that a "do nothing" binary is a useless tech demo
I chose it because, to a good approximation, the resulting size is
nothing but overhead. It is useless as far as its own functionality
goes; it is not useless in that it very clearly measures pure overhead.
I actually started out on Ubuntu, with a program
#include <stdio.h>
int main(void) { printf("Hello\n"); return(0); }
but, when my investigations took me to NetBSD, I started cutting it
back (largely because the 1.4T/sparc version of that weighs in at
39836/440/3000 and I wanted to see how much of that was printf - about
two-thirds, as it turns out). I first cut it back to <unistd.h> and
write(1,"Hello\n",6); and then finally all the way back to the one I
first posted here about.
> If you really want it, you could avoid libc and csu, and be down to a
> few bytes.
Yes. Writing it in asssembly I got it down to 12/0/0 on 1.4T/sparc
(clr %o0; mov 1,%g1; ta 0); I don't know amd64 assembly enough to write
the corresponding code there, but I would expect it to be comparable.
> Way more interesting than useless tech demo sizes would size
> inflation of a real world minimal program, when linked statically.
Why? If I'm looking at overhead size, I am most interested in just the
overhead size, which is exactly what a no-op program gives. If I want
to look at the overhead of printf, or malloc, or something, I'd use a
program that just calls those. That might be interesting, but it's not
what I was doing here.
Still, easy enough. I took 1.4T's /usr/src/games/random.c (picked by
looking at executable file sizes in /usr/games and eliminating the
shellscripts) - but I did remove the #ifdef lint / __COPYRIGHT / #endif
lines, because the 1.4T's random.c's version of that produces an
assembler-time error on 5.2/amd64 and 9.0_STABLE/amd64 (the \ns turn
into literal newlines in the .s, causing the assembler to complain
about unterminated strings). I'm using the resulting .c for all these
tests, even on other OS versions. I don't know how close that is to
your "real world iminimal program", but it seems reasonable to me.
1.4T/sparc:
[Sparkle] 252> cc -o main main.c; size main
text data bss dec hex filename
4565 248 280 5093 13e5 main
[Sparkle] 253> cc -static -o main main.c; size main
text data bss dec hex filename
49084 616 4068 53768 d208 main
[Sparkle] 254>
5.2/amd64:
[Backstop] 133> cc -o main main.c; size main
text data bss dec hex filename
4069 632 496 5197 144d main
[Backstop] 134> cc -static -o main main.c; size main
text data bss dec hex filename
175741 4760 19064 199565 30b8d main
[Backstop] 135>
9.0_STABLE/amd64 (ftp.n.o):
% cc -o main main.c; size main
text data bss dec hex filename
4419 666 520 5605 15e5 main
% cc -static -o main main.c; size main
text data bss dec hex filename
590110 29416 2178840 2798366 2ab31e main
%
> The other things that we *might* look into (if someone volunteers) is
> to better modularize the CSU code, but it is not immediately clear
> how that could/should be done.
I don't know. I'm going to be looking at it on my 1.4T and 5.2; if
anyone is interested in my results, if-and-when I have any, I can post.
But I don't know how applicable they will be to -current.
> However, I personally disagree with Jason on the static linking
> support
Me too. In my opinion, there is a very important place for executables
that depend on nothing outside themselves except the kernel. I've got
two chroots where it is very nice to have executables that _don't_ need
any other files to be present in order to work.
All my own libraries, all the stuff in /local/src/lib*, I build .a
libraries and no .so libraries. The only things I routinely link in
dynamically are the ones that come with the system, and not always even
those.
> It does not come for free though.
Nothing of value does.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
