tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] TCC 0.9.25 is out


From: Jerome Vuarand
Subject: Re: [Tinycc-devel] TCC 0.9.25 is out
Date: Tue, 14 Jul 2009 18:00:30 +0200

2009/7/12 grischka <address@hidden>:
> Jerome Vuarand wrote:
>> On the other hand, assuming that's the way tcc is going to stay, it
>> feels weird to pass the TCCState to tcc_get_symbol, while the returned
>> address is in fact dependent on the buffer passed to tcc_relocate.
>> Instead, it would feel more natural to copy the metadata in the user
>> buffer, and pass it (without the TCCState) to tcc_get_symbol.
>
> I don't know.  Maybe you have a point but it is hard to tell if we don't
> know what you are trying to do and how the changed interface would cause
> inconvenience (if any) with your specific case of usage.

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.

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).

>> 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, 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.




reply via email to

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