[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] autoconfiscation
From: |
Rob Landley |
Subject: |
Re: [Tinycc-devel] autoconfiscation |
Date: |
Wed, 29 Aug 2007 19:47:27 -0500 |
User-agent: |
KMail/1.9.6 |
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.
- Re: [Tinycc-devel] autoconfiscation, (continued)
Re: [Tinycc-devel] autoconfiscation, Shawn Rutledge, 2007/08/28
- Re: [Tinycc-devel] autoconfiscation, Jakob Eriksson, 2007/08/28
- Re: [Tinycc-devel] autoconfiscation, Gregg Reynolds, 2007/08/28
- Re: [Tinycc-devel] autoconfiscation, Rob Landley, 2007/08/28
- Re: [Tinycc-devel] autoconfiscation, Shawn Rutledge, 2007/08/28
- Re: [Tinycc-devel] autoconfiscation, Gregg Reynolds, 2007/08/29
- Re: [Tinycc-devel] autoconfiscation,
Rob Landley <=
- Re: [Tinycc-devel] autoconfiscation, Simon 'corecode' Schubert, 2007/08/30
- Re: [Tinycc-devel] autoconfiscation, Rob Landley, 2007/08/30
Re: [Tinycc-devel] autoconfiscation, Peter Lund, 2007/08/29
Re: [Tinycc-devel] autoconfiscation, Jakob Eriksson, 2007/08/29