Messages in this thread | | | From | Nick Desaulniers <> | Date | Tue, 22 Mar 2022 11:07:17 -0700 | Subject | Re: [RFC PATCH v2 2/8] tools/nolibc: Remove .global _start from the entry point code |
| |
On Tue, Mar 22, 2022 at 10:58 AM Willy Tarreau <w@1wt.eu> wrote: > > On Tue, Mar 22, 2022 at 10:30:53AM -0700, Nick Desaulniers wrote: > > On Tue, Mar 22, 2022 at 10:25 AM Willy Tarreau <w@1wt.eu> wrote: > > > The purpose is clearly *not* to implement a libc, but to have > > > something very lightweight that allows to compile trivial programs. A good > > > example of this is tools/testing/selftests/rcutorture/bin/mkinitrd.sh. I'm > > > personally using a tiny pre-init shell that I always package with my > > > kernels and that builds with them [1]. It will never do big things but > > > the balance between ease of use and coding effort is pretty good in my > > > experience. And I'm also careful not to make it complicated to use nor > > > to maintain, pragmatism is important and the effort should remain on the > > > program developer if some arbitration is needed. > > > > Neat, I bet that helps generate very small initrd! Got any quick size > > measurements? > > Yep: > > First, the usual static printf("hello world!\n"): > > $ ll hello-*libc > -rwxrwxr-x 1 willy dev 719232 Mar 22 18:50 hello-glibc* > -rwxrwxr-x 1 willy dev 1248 Mar 22 18:51 hello-nolibc*
! What! Are those both statically linked?
> This one supports ~30-40 simple commands (mount/unmount, mknod, ls, ln), > a tar extractor, multi-level braces, and boolean expression evaluation, > variable expansion, and a config file parser to script all this. The code > is 20 years old and is really ugly (even uglier than you think). But that > gives an idea. 20 years ago the init was much simpler and 800 bytes (my > constraint was for single floppies containing kernel+rootfs) and strings > were manually merged by tails and put in .text to drop .rodata.
Oh, so nolibc has been around for a while then?
ld.lld will do string merging in that fashion at -O2 (the linker can accept and optimization level). I did have a kernel patch for that somewhere, need to update it for CC_OPTIMIZE_FOR_SIZE...
I guess the tradeoff with strings in .text is that now the strings themselves are r+x and not just r?
> > You'll also note that there's 0 data segment above. That used to be > convenient to further shrink programs, but these days given how linkers > arrange segments by permissions that doesn't save as much as it used to, > and it's likely that at some points I'll assume that there must be some > variables by default (errno, environ, etc) and that we'll accept to invest > a few extra tens of bytes by default for more convenience.
Thanks for the measurements. -- Thanks, ~Nick Desaulniers
| |