tinycc-devel
[Top][All Lists]
Advanced

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

[Tinycc-devel] libtcc API v.s. global state v.s. tcc state


From: egodust
Subject: [Tinycc-devel] libtcc API v.s. global state v.s. tcc state
Date: Thu, 17 Apr 2008 18:41:01 +0100

Heyas all,

First of all, might I suggest some warnings in libtcc.h? It seems to
suggest that you
can allocate as many compiler states with tcc_new() as you want and
none will mess
with each other-- I was in for a shock when I looked at the code and it was
sapping globals left and right! from tcc state :(

libtcc seems to be coded for things such as (error checking not included):

tcc = tcc_new();
tcc_add_file(tcc, "blah.c");
tcc_relocate(tcc);
tcc_run(tcc);
tcc_delete(tcc);

A scheme where its expected the code life is exactly the same as the
compiler life,
but what if this isn't always the case?

If another 'tcc_new' is called inbetween, then the second tcc_new()
overwrites pointers
allocated to the globals, worst still, if two tcc_delete()'s are
called on the wrong pair,
it will dump :/

But when used in new/delete fashion, all is well, I suspect the
globals are used so
that not everything has to be pushed onto the stack, or dereferenced
from the state object?

Be that as it may, I was hoping to use libtcc to compile a set of C
files, and KEEP the
"in memory" output, and delete the compiler state so that it can compile other
files whilst only using "one" tcc_new/tcc_delete pair to get around
the globals limitation.

Because changing everything to use state from globals, is a huge
change and alot of
updates are needed, I thought of another way. So I made my own
changes, to get around
the problem with minimal fuss.

tcc_export_binary_image() and tcc_binary_image_free().

What happens is:

tcc = tcc_new();
tcc_add_file(tcc, "blah.c");
tcc_relocate(tcc);
binary = tcc_export_binary_image(tcc);
tcc_delete(tcc);
// code still valid.
// binary is now released from the compiler state
// and can continue to run without the compiler state that created it
tcc_binary_image_free(binary);

As you can see, you can use the compiler on as many C files as you like
and copy the binary (in memory) output somewhere til you know you want to
free it.

The TCCBinary structure is treated as opaque, you can't tcc_get_symbol(), or
do anything else with it, it's just held somewhere til the code/data it contains
can be freed (like say dlclose()'d)

I am not fully yet to grips with the codebase, what else is needed? I
have copied
the sections, are the DLL names needed?

I have tested it on simple C code (i.e. doesnt load DLLs) and the changes work,
I haven't included patches because this more of a discussion on the addition :)

Kind Regards,
Sam K

libtcc.h changes:

/* This function will 'export' all the binary image information
from the given tcc state, so that you can continue to run/use it,
even if the compiler state that created it has been freed.

Note: the associated compiler state must still be freed with
a call to tcc_free() as normal.

Once the binary image is no longer needed, you can free it with
tcc_binary_image_free()
*/
TCCBinary * tcc_export_binary_image(TCCState *s);

/* free the given image state, any code that is associated with it
is no longer valid after this call. */
void tcc_binary_image_free(TCCBinary *b);




reply via email to

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