i've been building a C package manager where the packages are written in
C and jitted as opposed to some crazy dsl or external scripting
language. hence my interest in tcc. it does pretty much everything i
need stock, but i was experimenting with how to debug the jitted code
with gdb.
it looks like this boils down to using gdb's builtin jit stuff
(__jit_debug_register_code, etc). you just give it a pointer to the elf
data and everything works nicely. and tcc obviously has a ton of nice
code for outputting to elf.
but the problem is twofold. (1) tcc only outputs elf objects to files.
nothing in the api for outputting to a buffer/realloc'ing a buffer and
returning. (2) i REALLY want the resulting object to be relocated, but
when tcc outputs an object it's obviously not relocated, since it's
expected to be linked in to some host program later.
i made a proof of concept where i do the relocation myself. but it's
very hairy and moreover feels wrong -- i just jitted the code. i know
where it is in memory. i know the offsets. why go through this dance of
generating an unrelocated object just to relocate it later?
i believe the fundamental mismatch is that tcc operates in either/or
mode. either you want an object file or you want to run it directly.
there's no idea of "i want to run directly, but also i want debug
symbols". this is understandable...
my question is just whether there's any chance of this work being
accepted as a patch to tcc, or if i should just fork. i have everything
working; it's not a lot of code, just another entry in libtcc.h that
outputs the elf to mem, relocated. i am happy to clean it up and submit
it...but if you dont think it will be useful/you just dont want it then
i'll just keep my fork.
in any case, thanks for the great library and thanks for reading
cheers,
spader
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
