lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lightning] Feature Request: Allow patching of st(x)i and ld(x)i


From: Paulo César Pereira de Andrade
Subject: Re: [Lightning] Feature Request: Allow patching of st(x)i and ld(x)i
Date: Mon, 2 Sep 2019 12:05:20 -0300

Em dom, 1 de set de 2019 às 15:27, Marc Nieper-Wißkirchen
<address@hidden> escreveu:

  Hi Marc,

> With the current version of GNU lightning, only moves and jumps can be
> patched with, say, jit_patch_abs. It would be nice if this could be
> enabled for loads and stores as well.

  If I understand correctly, you are talking about jit_patch_abs usages.
Actually, you can patch jit_movi() the same way as jit_jmpi(). For example:

    jit_patch_abs(jit_jmpi(), some_pointer);
    jit_patch_abs(jit_movi(0), some_pointer);

  In the above, jit_movi() would receive a dummy argument. The branch jit_*
wrappers do not even receive an argument both, to avoid too much usage of
dummy arguments, and also as somewhat of a helper to make sure to
patch all branch instructions.

  Patches for ldi* and sti* are mostly pointless, because it would mean the
address is not known while generating jit, but before calling jit_emit().
Otherwise, that would mean access to the generated code, for example, to use
jit_ldi* on a jit_label_t; for that could use movi and ldr, ldxr, and ldi
past the mov instruction, but writes are not allowed, the code is also
mprotect'ed read only.

(actually, check/lightning.c allows sematically ldi* and sti* on the code,
if to an already defined label, but that will give a bogus pointer inside
the IR, not really in the generated code).

  What really could be useful is patching ldxi* and stxi*. It can be done
now by hacking the opaque jit_node_t. If that is the suggestion, please let
me know, and a public interface can be created.

  Now, about patching ldxi* and stxi*, at some point some extra calls can
be added, to convert the immediate value in a pointer to metadata. At least
internally it should be added. The main reason is to have dynamically
assigned offsets to save/restore callee save registers in prolog/epilog,
instead of having the current format, with statically assigned offsets, and
in most case a large 'stack_framesize'.

  One example of converting an integer value to a jit_node_t was jit_arg*,
but that was because the arg could be a register or stack offset.

  There is also jit_rewind, that was created to avoid needing flags for
jit_prolog and jit_prepare, so, if jit_ellipsis is called, it might need
to 'rewind' the prolog/prepare until the ellipsis, as varargs functions
might need a different setup for arguments.

> --
>
> Marc

Thanks,
Paulo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]