Grug-pilled C programming is really fascinating. I'm recently interested in tcc for the same reason and handling some small bugs in it. It would be really appreciated if you can post your patch or your project in any place. After prudent testing, I think it would be great to merge these.
On Tue, Dec 30, 2025 at 7:21 AM Eric Raible <[email protected]> wrote: > > 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 _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
