tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] About the fuction gexpr ...


From: Rob Landley
Subject: Re: [Tinycc-devel] About the fuction gexpr ...
Date: Wed, 5 Sep 2007 00:37:13 -0500
User-agent: KMail/1.9.6

On Wednesday 29 August 2007 4:25:53 am Peter Lund wrote:
> On Sun, 2007-08-12 at 23:54 -0500, Rob Landley wrote:
> > My priorities are:
> >
> > A) breaking up the source code into smaller, more manageable chunks
>
> I still owe you some code there... :/
>
> > B) Making it build an unmodified linux kernel.

On this one, I'm trying to find the minimal amount of stuff I have to compile 
to get a kernel image I can boot under qemu, which will say "hello world" to 
either the serial port on the vga card.  (And then hang.)  Then I can try to 
get tcc to build that, and work my way up from there.  (Luckily, Peter 
Anvin's rewrite of the boot code in C was recently merged, which presumably 
makes this sort of thing much more accessable.)

The general approach I'm taking is:

A) read the old Linux Kernel Internals document that walks you through an 
(alas dreadfully obsolete) version of the boot code:
http://www.moses.uklinux.net/patches/lki-1.html

B) Run "make allnoconfig" and then make menuconfig to switch even _more_ stuff 
off.  (It's amazing how much stuff gets left _on_ by allnoconfig.  And you 
have to open the "configure standard kernel features" menu under general 
setup in order to switch off more stuff.)  Then run "make V=1" to see the 
actual command lines being run, comparing the output of that with a normal 
make.

Unfortunately, the first thing the kernel build does on x86 (other than some 
housekeeping stuff like creating symlinks) is:

gcc -m32 -Wp,-MD,arch/i386/kernel/.asm-offsets.s.d  -nostdinc -isystem 
/usr/lib/gcc/i486-linux-gnu/4.1.2/include -D__KERNEL__ -Iinclude -Iinclude2 
-I/home/landley/linux/hg/include -include 
include/linux/autoconf.h -I/home/landley/linux/hg/. -I. -Wall -Wundef 
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common 
-Werror-implicit-function-declaration -O2 -pipe -msoft-float -mregparm=3 
-freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -ffreestanding 
-maccumulate-outgoing-args 
-I/home/landley/linux/hg/include/asm-i386/mach-default 
-Iinclude/asm-i386/mach-default -fomit-frame-pointer -fno-stack-protector 
-Wdeclaration-after-statement -Wno-pointer-sign  -D"KBUILD_STR(s)=#s" 
-D"KBUILD_BASENAME=KBUILD_STR(asm_offsets)"  
-D"KBUILD_MODNAME=KBUILD_STR(asm_offsets)" -fverbose-asm -S -o 
arch/i386/kernel/asm-offsets.s 
/home/landley/linux/hg/arch/i386/kernel/asm-offsets.c

Which looks much scarier than it is.  The above is roughly equivalent to:

gcc -I include -S asm-offsets.s asm-offsets.c

And what it's doing is turning asm-offsets.c into asm-offsets.s, which it then 
runs a sed invocation against to generate asm-offsets.h, which is the point 
of the exercise.

Our problems:

A) we don't produce assembly output.  (One possible workaround is to use 
objdump on the .o file to get assembly, but this means we still can't build a 
linux kernel without binutils installed, and I'm not sure that gives the same 
output anyway.  That "-fverbose-asm" makes me especially nervous.  Maybe if 
we build with debug output objdump will be happy?)

B) asm-offsets.c doesn't compile with tcc.

> address@hidden:~/linux/temp$ tcc -I ../hg/include -I include2 -c -o woot.o
> ../hg/arch/i386/kernel/asm-offsets.c In file included from
> ../hg/arch/i386/kernel/asm-offsets.c:7:
> In file included from ../hg/include/linux/crypto.h:20:
> In file included from include2/asm/atomic.h:5:
> In file included from include2/asm/processor.h:16:
> In file included from include2/asm/cpufeature.h:11:
> In file included from ../hg/include/linux/bitops.h:9:
> In file included from include2/asm/bitops.h:9:
> include2/asm/alternative.h:9: ',' expected

Yup, the _very_first_file_, which is really just header info and structure 
definitions, died.  Wheee...

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]