2009/7/12 grischka <[email protected]>: > 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. _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
