Em qui, 12 de set de 2019 às 03:39, Marc Nieper-Wißkirchen
<address@hidden> escreveu:
Hi Paulo,
Hi Marc,
when creating a function prolog and epilogue for a trampoline
function
as this one
prolog
frame (...)
...
epilog
GNU lightning saves all callee-save registers in the prolog and
restores them in the epilog. On the Unix port of x86_64, however, it
fails to save and restore %r12, which is a callee-saved register.
(This error has led to subtle bugs when I compiled my code with
"-O2"
and gcc began to use %r12 and expected it to be preserved over a
call
into a GNU lightning trampoline.)
The error maybe related to the fact that on GNU lightning, %r12 is
mapped to JIT_R3, which appears as a caller-save register to the
user.
See also this discussion here:
https://lists.gnu.org/archive/html/lightning/2017-09/msg00006.html
I believe quite some time ago I had made a commit for this issue
in another computer, that I no longer have, and never pushed it.
For sure it will be added in the next release of GNU Lightning that
I am already working on. It just is taking more time than expected
due to issues with powerpc 32 bit abi, that previously I had tested
only on AIX, and when testing on Linux, it uses another ABI...
I'd suggest to apply the patch of this discussion so that %r12 is
treated like %13, %r14, %15 and will be automatically saved in the
prolog and restored in the epilog. The side effect will be that
JIT_R3
goes away and JIT_V4 appears.
The problem should go away as well if just changing:
{ rc(gpr) | rc(rg8) | 12, "%r12" },
to
{ rc(sav)|rc(gpr) | rc(rg8) | 12, "%r12" },
Then, there would be a JIT_R3 that actually is callee save, and
could
be checked with jit_callee_save_p. It does not really matter much,
but probably better to make it indeed JIT_V4, to make it more explicit
it is callee_save.
The issue is hard to find because it explicitly save/restore _R12,
in prolog/epilog if used in a jit function. But logic checking for
jit_class_sav will not work correctly when computing live registers,
%r12 will be treated as a scratch register.
If you don't want this, the bug has to be fixed differently by
patching the _prolog and _epilog procedures.
In any case, a fix of this bug is urgent because it is a critical
one
(as non-ABI-conforming code is produced).
Thanks,
Marc
Thanks,
Paulo
_______________________________________________
Lightning mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lightning