yes, this is exactly what i'm doing. generating an ELF in memory, doing
the relocations myself. i have no idea how to use a mailing list and i'm
not gonna figure out how to reply to several people at once, but
herman's patch is pretty close to what i'm doing. except i generate to
memory instead of to a file, and use gdb's jit hook to load it.
everything compiled to memory.
works great. 0 manual interaction from the user.
not totally sure that this is worth being merged in to the minimal
libtcc though. i mean, maybe. here's mine:
https://github.com/TinyCC/tinycc/compare/mob...tspader:tinycc:spn
as you can see, barely any code. of course, i'm doing zero validation.
just hacked it.
is it more complicated than this? cyan, you mentioned doing relocations
yourself. why? is there a problem with the approach me/herman used?
(write elf after relocation, automatically get relocated addrs)
On 2026-01-06 14:31, Cyan Ogilvie wrote:
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
