I would be very interested in being able to gdb libtcc-generated code. My project involves interleaved AOT and libtcc-generated jitted code and it confuses gdb 100% of the time. I'm not going to be of much use for developing the enhancement but will gladly text it on arm64 Linux.
On Mon, Dec 29, 2025, 1:03 PM spader via Tinycc-devel < [email protected]> wrote: > 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 >
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
