Re: [Lightning] How to get call address / instruction pointer without a hack?

[Paulo César Pereira de Andrade]

2014-03-09 14:43 GMT-03:00 Paulo César Pereira de Andrade
<address@hidden>:
> 2014-03-09 12:05 GMT-03:00 Bruno Loff <address@hidden>:
>> Hello again :-)
>
>   Hi :-)

  Bruno,

  I am considering to experiment with some features that would make what
I understand from your needs from lightning a lot easier.

  So, adding to my TODO, in order of difficulty and guessed time required to
implement:

1) jit_set_ip(ptr, size) -- this should be done before the first
jit_xyz call, so
   that jit_emit would not allocate memory, but write code to ptr, and would
   return null if the code would not fit in size bytes.
   As an extra feature, could export jit_get_size() that is a private function
   that returns the expected size in bytes of the code before emitting code.
2) jit_retaddr(jit_gpr_t) that would set the gpr register argument, at runtime
   to the return address of the current function. This would be kind of gcc
   __builtin_return_address, but only work for the return address of the
   current function.
3) jit_nodata or similar name. jit_name and jit_note would still work for
   jit_address, but constants would not use a separate data buffer, instead
   would use a stack scratch buffer to synthesize constants that cannot
   be directly created. Note that it uses a (read only) data buffer only to not
   mark the constants as executable, otherwise could put the data before or
   after the code.
4) jit_relocate(void *where) that would relocate the jit code after emit.
   This would require saving several pointers to be patched, so, this is
   at first unlikely to be implemented, because it would be basically
   done after throwing away the IR, instead, it probably would be better
   to add an intermediate pass, or some kind of callback mechanism to
   jit_emit. As a side note, it is worth mentioning that jit_patch_abs exists,
   and is usable for jit_movi and jit_jmpi, but only use cases I can imagine
   are when using multiple jit_context_t and using addresses after one of
   the contexts has been emitted, as all other addresses are expected to
   be constant at runtime or can be resolved before actual jit emit, e.g.
   dlopen+dlsym.


  If you, Bruno, or anybody else have suggestions, please let me know.

Thanks,
Paulo