I'd really like to see this - I've had the same requirement (from a different direction, debugging embedded C in a scripting language environment. I went a long way down the rabbit hole of generating object code, doing the relocations myself and informing gdb about it using its jit hooks. It kinda worked but didn't feel like a sane approach for a production grade component. In the end I had to fall back to generating a shared lib and loading that with dlopen, but that comes with its own set of tradeoffs (musl doesn't free memory on dlclose, so the jit leaks, have to manage temporary files with cleanup on crashes, etc.)
For my use case, what I'd really like the most would be TCC's direct to memory compile mode, with the option of debug integration with gdb (source file info is tricky though, doesn't necessarily exist as a physical file anywhere on disk in my case). I went as far as building an in-process FUSE mountpoint provider for the temporary files, but that makes it Linux specific, requires that the process has elevated permissions and also not sane complexity to pay for this facility. Cyan On Mon, Dec 29, 2025 at 6: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
