I've looked some at libtcc and it looks to me like it could be very useful for some development tools I've been considering developing.
Libtcc in it is current form seems to only be intended for use by the application linked to it. For my own tools that I'm considering developing, libtcc would need to modified some in order to be more effective. /* copy code into memory passed in by the caller and do all relocations (needed before using tcc_get_symbol()). returns -1 on error and required size if ptr is NULL */ LIBTCCAPI int tcc_relocate(TCCState *s1, void *ptr); The main problem for me right now is that the process that I intend to target will not be that same as the process that is linked to libtcc, and may not even be on the same machine. (Might be on a machine with much more limited resources as well or might be because I don't want the target process to drag down my host "IDE if you want to call it that" process if the target application gets hosed and restarted). I've looked some into making an additional tcc_relocate, one that accepts a third argument, say something like "void *target_base" where "target_base" is the address in the target process that is the same size as the block "ptr" references. That way one could compile code on the fly for a remote target process (or just a separate process on the same machine) and all the relocations would be calculated based on where the code needs to actually be used. My primary intent for libtcc would be to compile code incrementally on the fly in one process for another process, and run code in the target process on demand, or even be injecting code into the running process on the fly to be used later. I don't see any real technical obstacles here, I've done this on this on other systems and know all the ramifications for this kind of cross compilation and host/target development. I'd like to know if there is anything about the current design of libtcc before I seriously consider actually making an additional tcc_relocate that meets my requirements. Initially it looks like I would need to compile each code in a separate TCC State and update the symbols for each subsequent TCC State. I'd like to look investigate as well what it would take to not use additional states, and just use the same state, and doing delta management as opposed to managing multiple TCC State segments, which may quickly snowball in terms of symbol management depending on the type of application I'd be using this in. On a side note: tcc does not build cleanly on 64 bit for 64 bit development. It has some warnings which are very disturbing, "warning: cast to pointer from integer of different size" and "warning: field width should have type ‘int’, but argument 3 has type ‘long int’" . If I do pursue libtcc for anything I do, the first thing I'm going to need is turn on -Werror for the compile options and correct all the sizes, and in the end have with patches to submit. (My approach for this sort of thing is to always correct the sizes where need and never massage the casts). I'm not promising anything though.... Dwight _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
