[Tinycc-devel] libtcc could be made more multipurpose

[Dwight Schauer]

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