Re: [Tinycc-devel] TCC 0.9.25 is out

[grischka]

Jerome Vuarand wrote:
> I'm writing a libtcc binding for a dynamic language with a garbage
> collector, and I need to keep track automatically of interdependencies
> of 'objects' (in a very broad sense) so as to free the user from
> having to deal with allocation and especially deallocation himself.

> For example, if all the pointers returned by tcc_get_symbol depend on
> the block of memory passed to tcc_relocate, I have to tell my garbage
> collector not to release the memory block as long as there are
> pointers accessible. If the pointers also depend on the TCCState, I
> can also tell my garbage collector not to close the state as long as I
> have pointers.

A pointer always can point to only one thing. Therefore two different
things can never depend on the same pointer.

> Globally I feel that the precise dependency graph between objects
> manipulated by libtcc was very clear before that tcc_relocate change,
> and it's much less clear now (but that can very well be a simple lack
> of documentation/explanation).

I guess there is not much to explain beyond what is shown in the
libtcc_test example.

> > > Finally the lifetime of the memory block passed to tcc_relocate is not
> > > clear to me. Can I delete the TCCState and still use symbols created
> > > by it as long as the memory block is valid ?
> > The lifetime of the memory block is until you free it,  and as long as
> > it's valid, any addresses that point to it are valid too.
>
> Then what is not clear to me, is which ones of the addresses returned
> by tcc_get_symbol refer to what block of memory, hence my previous
> remark.  Of course I can assume that the symbols refer to the last
> block passed to tcc_relocate, but as much as it may be obvious to you
> since you wrote the change, ...

No, that is not obvious.  Basically there may be symbols (such as when
added with tcc_add_symbol) that do not point into the compilation block,
or aren't addresses at all.

But this problem exists with and without the API change.   Maybe you just
were not aware of it previously.

> ... from a user point of view if it's not
> written in the doc we can't assume anything to be true (and it
> wouldn't be the first time that a library API has unintuitive
> peculiarities).

> > > Is freeing the block
> > > enough to free any resource (OS handles, temporary files, etc.) that
> > > is needed to support the relocated code ?
> > No.  The free() call in C does only one thing: free the memory. If there
> > are open OS handles stored in that memory, it is your problem.
>
> Actually I don't store anything in there myself, I'm just wondering if
> no such OS handle is necessary to keep that block of memory
> executable.

Now that I think of it we have possibly handles to dlls and these are
currently stored in TCCState, which indeed is incorrect with the interface
change.

Anyway, probably you are right that the change adds more confusion than
real benefits.  So we might as well change back to the previous layout
and manage the code block internally. (FYI the relocation into a continuous
memory area was necessary to support 64-bit targets.)

--- grischka