[Top][All Lists]

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

Re: [Tinycc-devel] TCC 0.9.25 is out

From: grischka
Subject: Re: [Tinycc-devel] TCC 0.9.25 is out
Date: Mon, 27 Jul 2009 20:13:06 +0200
User-agent: Thunderbird (Windows/20070221)

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

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

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

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

reply via email to

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