Re: [Tinycc-devel] autoconfiscation

[Rob Landley]

On Wednesday 29 August 2007 6:05:46 am Gregg Reynolds wrote:
> On 8/28/07, Rob Landley <address@hidden> wrote:
> ...
>
> > Building the entire project, including all cross compiler targets, the
> > build currently does this:
> >
> > cc -O2 -g -Wall -fsigned-char -Os -mpreferred-stack-boundary=2 -m386 \
> >         -malign-functions=0 -o tcc tcc.c -lm -ldl
> > cc -O2 -g -Wall -fsigned-char -Os -mpreferred-stack-boundary=2 -m386 \
> >         -malign-functions=0 -DTCC_TARGET_ARM -DTCC_ARM_EABI \
> >         -o arm-tcc tcc.c -lm -ldl
> > cc -O2 -g -Wall -fsigned-char -Os -mpreferred-stack-boundary=2 -m386 \
> >         -malign-functions=0 -DTCC_TARGET_C67 -o c67-tcc tcc.c -lm -ldl
> > cc -O2 -g -Wall -fsigned-char -Os -mpreferred-stack-boundary=2 -m386 \
> >         -malign-functions=0 -DTCC_TARGET_PE -o i386-win32-tcc tcc.c -lm
> > -ldl cc -O2 -Wall -c -o libtcc1.o libtcc1.c
> > cc -c -o i386/alloca86.o i386/alloca86.S
> > cc -c -o i386/bound-alloca86.o i386/bound-alloca86.S
> > ar rcs libtcc1.a libtcc1.o i386/alloca86.o i386/bound-alloca86.o
> > cc -O2 -Wall -c -o bcheck.o bcheck.c
> > cc -O2 -g -Wall -fsigned-char -Os -mpreferred-stack-boundary=2 -m386 \
> >         -malign-functions=0 -DLIBTCC -c -o libtcc.o tcc.c
> > ar rcs libtcc.a libtcc.o
> >
> > The above can actually be _simplified_ somewhat, I suspect.  Why,
> > exactly, does this need more complexity than a very small shell script?
>
> I just came across http://kegel.com/crosstool/ and took a (very) quick
> look at the code.  It builds gcc/glibc across a gazillion platforms,
> but it looks like it does it all with bunch of small shell scripts.

Unfortunately it's very version dependent (a separate case for each dot 
release of each tool on each platform, last I checked), and it also uses lots 
of version-specific patches.

I looked at that before doing Firmware Linux...

> Which is essentially what we'd want for tcc, only on a smaller and
> less hairy scale, and with a simple configure/makefile instead of the
> Autotools build system gcc uses.  I think it's worth looking at as a
> model for a tcc system, especially since a c compiler wants a c
> standard lib.  It would be nice to be able to tell the build system
> something like "Go forth, and build ye me a tcc compiler with a uClibc
> library!".

Currently, tcc doesn't care what libc you're using.  It links against libc.so 
which is usually a symlink to your system's default C library.

A compiler like gcc has six interesting paths:

  1) Where do the compiler-supplied headers live.  (varargs.h and friends)
  2) Where do the system headers live (stdio.h and friends)
  3) Where do the compiler-supplied libraries live (libtcc1.a, crtbegin.o)
  4) Where do the system libraries live (libc.so, crt1.o, etc)
  5) Where do the other executables (cpp, ld) live.
  6) Where do source files come from?  (Current working directory.)

The fact that #5 isn't just $PATH is because gcc is "special".  A sane 
implementation wouldn't special case that one, or #6.  So that's two header 
paths and two library paths to search, and you should be done.

Now there are some special files you link against by default: libc.so and the 
crt* files.  Here's Eric Andersen explaining to me what the crt*.o files do 
(I asked):
http://busybox.net/lists/uclibc/2003-September/006857.html

This thread is was educational too:
http://busybox.net/lists/uclibc/2003-September/006871.html

I believe --nostdlib makes it not link against the crt* files by default, as 
well as libc.so.

My darn wrapper script zaps all the gcc paths and replaces them with explicit 
ones on the command line, and to do this right it has to know what they all 
_are_ as well as parse the gcc command line including some weird corner cases 
used by thing like the kernel build:
http://landley.net/hg/firmware/file/827b76efba8e/sources/toys/gcc-uClibc.c

I'm tring to remember the difference between crt1.o and crt0.o.  I think the 1 
version is thread-safe, or some such.  I forget, and I can't find where I 
asked Erik...

The reason you can't run a glibc version of gcc against uClibc is that pieces 
of gcc like libgcc_s.so link against their libc, and leak references to that 
libc.  So if you ever divide by a 64 bit number on a 32 bit platform or weird 
corner cases like that, a reference to glibc sneaks into your uClibc program.  
Since libgcc is part of the gcc source code, the only way to build a version 
of that library which leaks a reference the _right_ libc is to rebuild gcc 
against uClibc, from source code.

The way tcc handles this is not NOT LEAK.  This is a much better solution, and 
there's no reason you can't have a single tcc binary link against glibc or 
uClibc simply by feeding it different search paths.

Are the search paths currently configurable enough?  No.  But if you know what 
they _are_, you can fix that. :)

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.