[qcc] Hello world.

[Rob Landley]

On 06/23/2012 05:32 AM, orc wrote:
> Or there is not so much work needed?

I maintained a fork of tinycc for several years (check the repo
history), and the general infrastructure already works.

This is mostly because tcc was already pretty complete: back when
Fabrice bellard abandoned it he'd already gotten it to build a bootable
subset of the Linux kernel (tccboot) and he wrote up a todo list of what
was needed to build an _unmodified_ Linux kernel, and for full c99 support:

  http://bellard.org/tcc/tccboot_readme.html

Since then most of that todo list has been accomplished (althoguh
variable length arrays are still pending, a c99 feature the kernel
apparently actually uses), but the _current_ todo list has expanded
quite a bit with busybox and linux 2.6/3.0.

Busybox and toybox both require simple dead code elimination, because
the config system does if(ENABLE) function() and then doesn't link in
the .o file containing function() if the ENABLE is a constant 0 because
the config symbol is switched off. I.E. it expects if(0) not to produce
any code.

Also, to build 2.6 we need a _disassembler_, because the build creates a
.o file and then runs it through objdump. Tinycc provides an assembler,
but not a disassembler. That's target-specific.

Also, stuff tinycc does needs to be available under individual command
names.  The assembler needs to be callable as as, the linker as ld, the
preprocessor as cpp, and so on. It needs code to read _in_ ELF objects
so it can do strip and objcopy and such. Plus it needs a "make"
implementation, which isn't a _huge_ deal but is a reasonable amount of
work.

Most of the work I did on my old fork was breaking up the giant
monolithic lump to work towards this. Of course the Zombie Project
thought that was useless and refused to take it, and the version skew
between the refactored and non-refactored versions made taking patches
from them really difficult. (In retrospect that's great because it's
fewer people to track down to get relicensing permission from, or whose
code needs to be removed.)

Finally, there's the various target support, which is where QEMU's tcg
comes in. Right now, qemu already has a mechanism to read/write code for
each target, and I'd like to leverage that precisely so the qemu guys
are the ones doing 95% of the target support work. In theory, when they
get a new target working, we get it for free. (They even have to be able
to parse ELF executables so the application emulation can run binaries
and link shared libraries.)

In practice, we'll still need to do an assembler/disassembler for each
target, and who knows what else...

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

 1340646966.0