tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] Porting TCC to RTLinux


From: Rob Landley
Subject: Re: [Tinycc-devel] Porting TCC to RTLinux
Date: Wed, 22 Nov 2006 14:23:41 -0500
User-agent: KMail/1.9.1

On Wednesday 22 November 2006 12:25 pm, Calin A. Culianu wrote:
> 
> Hi,
> 
> I am trying to get tinycc-0.9.23 to exist as an embedded facility in the 
> linux kernel.

The ability to build tcc as a kernel module makes a certain amount of sense.

> 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'm under the vague impression that tccboot already did that.

> I reduced it  
> to a program that can only compile strings only (no files) and can't use 
> include files, etc.

Somebody wanted to add a facility to tcc so it could accept C code from stdin, 
and somebody else _did_ add a -E option so it could spit out a preprocessed 
file.  Having a userspace tcc pass a preprocessed file to a kernel tcc module 
sounds amusing...

The accept-from-stdin thing was just a request for feature, I didn't see 
anybody come up with a patch.  I haven't been particularly active since 
Fabrice rendered my tree moot last month, but I've still been reading the 
list and haven't seen it wander by...

> 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.

It would be nice if you could stick all this in a .c or .h file that could be 
optionally #included (#define printf printk and so on) so that the baseline 
version could build as a module.

Heck, if you came up with that I'd dust off my tree and merge it there.

> 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.

Ok, cleaning that up is one patch.

Since you already replaced malloc(), it should be easy enough to wrap your new 
calls to that with something that records where each allocation was made 
from.

Make a macro that adds the pointer returned by each allocation to a linked 
list along with the __FILE__ and __LINE__ of the call site, and then a 
similar one for free() that traverses the linked list to remove that 
allocation: yes this is hideously inefficient but after a run the list 
contains all your leaks and this works _everywhere_.

> That's one potential source of bugs.
> 
> Another is that I fear TCC may exhaust the kernel stack (which is 
> tiny at 8kb).

On newer kernels it's 4k.  Yeah, that's a real issue.

> 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.

Easier to figure out a way to swap stacks.  There was discussion about this on 
linux-kernel...  6 months ago?

> 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.

Yes please.

> -Calin

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery




reply via email to

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