[Tinycc-devel] Porting TCC to RTLinux

[Calin A. Culianu]

Hi,

I am trying to get tinycc-0.9.23 to exist as an embedded facility in the 
linux kernel.

Sound crazy?  Want to know why?

Well, the reason for this is that I am writing a realtime linux control 
application that runs in kernel context (under rtlinux).  My control 
application dynamically generates a turing machine (basically a finite 
state machine with memory and variables) which then gets run as a realtime 
task.

Anyway, so I need to be able to generate C code and compile it in the 
kernel.  This code then gets run in "realtime context" under rtlinux. 
Enter tcc, which promises to solve all my problems.

So far so good -- I ripped out the userspace-dependent portions of TCC and 
got rid of its dependencies on things like the C libraries.  I reduced it 
to a program that can only compile strings only (no files) and can't use 
include files, etc.  All print statements were replaced with printks, 
malloc were replaced with kmalloc/vmalloc (depending on memory size) and 
setjmp/longjmp were replaced with custom-coded asm versions since I don't 
have the C library as a resource.  I also had to implement strtod, etc in 
the kernel (making sure to save the FPU context and disable interrupts 
whenever handling floats), etc.

It works.. mostly.  However, I am experiencing stability problems and I 
am not sure what they could be due to.

One thing I noticed is that tcc does leak memory.  Basically, tcc_delete() 
doesn't gracefully clean up *all* pointers that were obtained when 
creating a TCCState with tcc_new().  Since my application needs to run 
forever, recompiling dynamically generated code a few times per minute, 
any memory leaks are unacceptable for my needs.  I observed that multiple 
tcc_new() / tcc_delete() pairs eventually exhaust system memory.

That's one potential source of bugs.

Another is that I fear TCC may exhaust the kernel stack (which is 
tiny at 8kb).  I am working on that second issue by carefully auditing 
the code for any large buffers put on the stack.  However there are no 
guarantees that at runtime TCC doesn't end up recursing heavily as its 
parsing C code.  I may have to figure out a way to grow the kernel stack 
forcibly.

Anyway, any insights or help with the memory leaks would be appreciated. 
Do newer versions of TCC addess these leaks?

PS: If anyone is interested I can post the code to my "embeddified" 
version of tcc.

-Calin