From: "egodust": > Heyas all, > 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? > 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. > tcc_delete(tcc); > // code still valid. > // binary is now released from the compiler state > // and can continue to run without the compiler state that created it > tcc_binary_image_free(binary); 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)) ; > 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. > 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. > Kind Regards, > Sam K Thanks, --- grischka _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel