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: Marc Nieper-Wißkirchen
Subject: Re: [Lightning] Feature Request: Allow patching of st(x)i and ld(x)i
Date: Mon, 2 Sep 2019 17:17:08 +0200

Hi Paulo,

Am Mo., 2. Sept. 2019 um 17:05 Uhr schrieb Paulo César Pereira de
Andrade <address@hidden>:
>
> 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().

This is exactly the case here. My code generator, which calls GNU
lightning, handles literals (of the source language) by storing their
addresses in a table, which is malloc'd. The size of the table is not
known until all code has been generated (that is, just before the call
to jit_emit). Therefore, the table cannot be malloc'd before and its
absolute address is not known before. However, needs to reference
entries in the table, so I have to patch it when the table has been
malloc'd.

Currently, I do something like:

lbl = jit_movi (JIT_R0, 0);
jit_ldr (JIT_R1, JIT_R0);
...
jit_patch_abs (lbl, table_pointer + offset);
jit_emit ();

What I want to do is:

lbl = jit_ldi (JIT_R1, 0);
...
jit_patch_abs (lbl, table_pointer + offset);
jit_emit ();

-- 

Marc

> 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]