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

[egodust]

Heyas,

On Thu, Apr 17, 2008 at 9:16 PM, grischka <address@hidden> wrote:

>  > First of all, might I suggest some warnings in libtcc.h?
>
>  Maybe a TODO entry?

:)

>
>
>  > I was in for a shock when I looked at the code and it was
>  > sapping globals left and right! from tcc state :(
>
>  True.
>
>
>  > 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 ...
>
>  But you could compile all C files into one state, no?

libtcc can be made more useful if you can compile several binary
images and run them (like memory loaded DLLs) without having them
share the same compiler state, i.e. the namespace. What if I wanted
two files to share an exported Load()?

It's possible to do, but soon as you have created the compiled object,
you can't keep it around longer than the compiler that made it :)

>
>
>  > Because changing everything to use state from globals, is a huge
>  > change and alot of updates are needed,
>
>  Also true.
>
>
>  > 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);
>
>  At this point it needs to call tcc_get_symbol() to get the entry
>  function address(es) for later.

Yep, but the caller to tcc_export_binary_image() grabs all the export
addresses (and such) using tcc_get_symbol() *before* they "cut" the
image free from the compiler state, after its a binary object, you can
only treat it like an opaque handle.

>
>
>  That is certainly possible.  You could pass in a user malloc pointer,
>  then tcc_binary_image_free() is redundant.
>
>     tcc_export_binary_image(TCCState, void *(*malloc_fn)(size_t)) ;
>

The caller passing their own malloc would suggest the function will
allocate a new copy from TCCState*.

My version of tcc_export_binary_image() just *moves* the pointers
inside the state structure into the "binary" structure, tcc still owns
the memory, thats why *free() is needed, tcc_free() doesn't deep free
and tcc_delete() only works on TCCState objects.

Once the move has been done, tcc_delete() doesn't delete the binary output, etc.

>
>  > I am not fully yet to grips with the codebase, what else is needed? I
>  > have copied the sections, are the DLL names needed?
>
>  No, just the sections with the SHF_ALLOC bit.

Thanks for the info :)
>
>
>  > 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 :)
>
>  Yes, could be useful.

I have included the patches to libtcc.h and tcc.c
>
>
>  Thanks,
>  --- grischka

Regards,
Sam

libtcc_newapi.patch
Description: Binary data

tcc_newapi.patch
Description: Binary data