Heyas, On Thu, Apr 17, 2008 at 9:16 PM, grischka <[EMAIL PROTECTED]> wrote:
> > First of all, might I suggest some warnings in libtcc.h? > > Maybe a TODO entry? :) > > > > I was in for a shock when I looked at the code and it was > > sapping globals left and right! from tcc state :( > > True. > > > > Be that as it may, I was hoping to use libtcc to compile a set of > > C files, and KEEP the "in memory" output, and delete the compiler > > state so that it can compile other files ... > > But you could compile all C files into one state, no? libtcc can be made more useful if you can compile several binary images and run them (like memory loaded DLLs) without having them share the same compiler state, i.e. the namespace. What if I wanted two files to share an exported Load()? It's possible to do, but soon as you have created the compiled object, you can't keep it around longer than the compiler that made it :) > > > > Because changing everything to use state from globals, is a huge > > change and alot of updates are needed, > > Also true. > > > > I thought of another way. So I made my own changes, to get around > > the problem with minimal fuss. > > tcc_export_binary_image() and tcc_binary_image_free(). > > > > What happens is: > > > > tcc = tcc_new(); > > tcc_add_file(tcc, "blah.c"); > > tcc_relocate(tcc); > > binary = tcc_export_binary_image(tcc); > > At this point it needs to call tcc_get_symbol() to get the entry > function address(es) for later. Yep, but the caller to tcc_export_binary_image() grabs all the export addresses (and such) using tcc_get_symbol() *before* they "cut" the image free from the compiler state, after its a binary object, you can only treat it like an opaque handle. > > > That is certainly possible. You could pass in a user malloc pointer, > then tcc_binary_image_free() is redundant. > > tcc_export_binary_image(TCCState, void *(*malloc_fn)(size_t)) ; > The caller passing their own malloc would suggest the function will allocate a new copy from TCCState*. My version of tcc_export_binary_image() just *moves* the pointers inside the state structure into the "binary" structure, tcc still owns the memory, thats why *free() is needed, tcc_free() doesn't deep free and tcc_delete() only works on TCCState objects. Once the move has been done, tcc_delete() doesn't delete the binary output, etc. > > > I am not fully yet to grips with the codebase, what else is needed? I > > have copied the sections, are the DLL names needed? > > No, just the sections with the SHF_ALLOC bit. Thanks for the info :) > > > > I have tested it on simple C code (i.e. doesnt load DLLs) and the changes > work, > > I haven't included patches because this more of a discussion on the > addition :) > > Yes, could be useful. I have included the patches to libtcc.h and tcc.c > > > Thanks, > --- grischka Regards, Sam
libtcc_newapi.patch
Description: Binary data
tcc_newapi.patch
Description: Binary data
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
