Re: [Tinycc-devel] tcc_relocate() and tcc_relocate_ex()

[David Mertens]

Sean Conner pointed out:
> ... snip ...
>
> Case 2:  Lua (http://www.lua.org/)
>
>   Just to recap Lua---it's a small scripting language intended to be
> embedded in a larger application to give said application scripting
> abilities.  You can also load additional modules either written in Lua or
> written in C (as shared objects, either .so for Unix or .dll for Windows).
>
>   Anyway, I wrote Lua bindings for libtcc [1], so from within a Lua script,
> I can include C code, compile it and then call the newly compiled C code
> from Lua (you can see an example of this starting with line 112 of [2]).
> Just as with case 1, once the code is compiled, I don't care about the rest
> of the TCCState---just the compiled code.
>
>   In fact, I use the libtcc bindings to extend Lua's require() function to
> compile a Lua module upon loading it, and have Lua manage the memory for the
> resulting code automatically (Lua is a garbage collected language).
>
>         [1] https://github.com/spc476/lua-conmanorg/blob/master/src/tcc.c
>         [2] https://github.com/spc476/lua-conmanorg/blob/master/lua/cc.lua

I have been working, on-and-off, on Perl bindings for TCC. I have
lamented that I have to carry around the whole compiler state after
having compiled because, as Sean writes, cleaning up the compiler
state also destroys the machine code. After the compile step, all I
need is the machine code. If there were some way to manage the memory
on my end, that'd be great.

If tcc_relocate_ex can eliminate this concern, then I am *VERY*
interested in knowing about it. :-)

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan