Stuff dragged in by crt1 (was Re: Announce: initrd-tftp 0.1)

From: Zack Weinberg (zack@wolery.cumb.org)
Date: Mon Jan 10 2000 - 01:54:01 EST


>>Even if you don't want them, you end up linking in malloc, stdio, and other
>>large chunks of useless stuff because the init/shutdown code (crt*.o) needs
>>to initialize these subsystems. Some clever changes to libc would
>>dramatically improve this situation, but it would take some work. Someday,
>>perhaps I'll have a chance...
>
>You can make things quite a lot better by including these lines in your
>program:
>
>exit() { }
>abort() { }
>atexit() { }
>void *__libc_stack_end;
>
>The latter is really a granularity problem with libc but the first three are
>probably to be expected. There's no easy way to avoid that excess code being
>linked in without imposing additional runtime overhead.

Actually, it is not hard at all - I just hacked up devo libc to produce a 4k
stripped static executable from

int main(void)
{
   write(1, "hello world\n", 12);
   return 0;
}

exit() and atexit() are quite small in themselves, but they drag in malloc,
and malloc drags in stdio, and stdio drags in gconv and the dynamic loader.
I created an internal entry point that doesn't use malloc, which is safe
because we're executing before any user code does so we know we have room
in the static atexit table.

abort() goes to great lengths to ensure that all buffered stdio output is
flushed, and therefore drags in stdio, etc. In the place where crt1 calls
abort, there can't possibly be any buffered stdio output, and neither can
there be a handler for SIGABRT, so we can just call kill.

__libc_stack_end was being defined in the wrong place, and would drag
in the dynamic loader, which uses malloc and stdio.

A remaining annoyance is that if you add a call to malloc() to the above,
it bloats back up to 237k. This is because the MALLOC_CHECK stuff refers
to stdio. I would personally like to see all that ripped out to a preload
library, or even scrapped, but I doubt I'll get my wish. It would also
be nice if wide streams and multibyte support didn't get pulled in unless
you actually used them. That would be much harder, but libio without
wide streams and all the junk it refers to is only about 100k (I think).

zw

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:15 EST