3 ms·

It might be best to emit machine code directly to memory. Template JIT style. Removes hazards like the C compiler putting jump tables in .rodata, has some nice

It might be best to emit machine code directly to memory. Template JIT style. Removes hazards like the C compiler putting jump tables in .rodata, has some nice properties like you can emit calls to functions in the address space as literal address instead of using a loader to patch them from relocation tables.

secondcoming 3y ago
That's interesting about jump tables in .rodata. That would break everything indeed. I really want the C compiler to do all the work. If I was to emit the machine code myself it would end up just being stack based anyway, I think.
- JonChesterfield 3y ago
  If you want to keep the call into a C compiler, you might want to go with freestanding (no calling into glibc by accident) and position independent, see if you can get everything statically resolved. Nothing in the loader relocation tables. Then mmap the entire elf. That gives you tables of constant data and removes all the edge cases that come from carving .text out. If you're partly looking for a easy and sufficient answer, and are building an elf anyway, much like the sibling post, I'd think dlopen is probably the way to go. Beware that dlclose might be a no-op, in which case eventually the address space leak will sink you.
- noelwelsh 3y ago
  Maybe libgccjit, then? https://gcc.gnu.org/onlinedocs/jit/ https://gcc.gnu.org/onlinedocs/jit/
samsquire 3y ago
I wrote the beginnings of a JIT compiler here (with help from Martin Jacob) https://GitHub.com/samsquire/compiler https://GitHub.com/samsquire/compiler See jitcompiler.c The code might be helpful.
pritambaral 3y ago
> ... you can emit calls to functions in the address space as literal address instead of using a loader to patch them from relocation tables. Technically, dlopen can do this too, except it'd make dlopen() slower. My toy compiler's C backend does just that: emit ELF files with relocation tables but load them and patch all relocations to direct addresses instead of PLT/GOT jump.

secondcoming 3y ago

That's interesting about jump tables in .rodata. That would break everything indeed. I really want the C compiler to do all the work. If I was to emit the machine code myself it would end up just being stack based anyway, I think.

JonChesterfield 3y ago
If you want to keep the call into a C compiler, you might want to go with freestanding (no calling into glibc by accident) and position independent, see if you can get everything statically resolved. Nothing in the loader relocation tables. Then mmap the entire elf. That gives you tables of constant data and removes all the edge cases that come from carving .text out. If you're partly looking for a easy and sufficient answer, and are building an elf anyway, much like the sibling post, I'd think dlopen is probably the way to go. Beware that dlclose might be a no-op, in which case eventually the address space leak will sink you.
noelwelsh 3y ago
Maybe libgccjit, then? https://gcc.gnu.org/onlinedocs/jit/ https://gcc.gnu.org/onlinedocs/jit/

samsquire 3y ago

I wrote the beginnings of a JIT compiler here (with help from Martin Jacob) https://GitHub.com/samsquire/compiler https://GitHub.com/samsquire/compiler See jitcompiler.c The code might be helpful.

pritambaral 3y ago

> ... you can emit calls to functions in the address space as literal address instead of using a loader to patch them from relocation tables. Technically, dlopen can do this too, except it'd make dlopen() slower. My toy compiler's C backend does just that: emit ELF files with relocation tables but load them and patch all relocations to direct addresses instead of PLT/GOT jump.