lightning
[Top][All Lists]
Advanced

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

Re: jit_stxi() is broken on PowerPC 64


From: Paul Cercueil
Subject: Re: jit_stxi() is broken on PowerPC 64
Date: Sat, 14 May 2022 23:52:06 +0100

Hi Paulo,

Le sam., mai 14 2022 at 18:04:47 -0300, Paulo César Pereira de Andrade <paulo.cesar.pereira.de.andrade@gmail.com> a écrit :
Em sáb., 14 de mai. de 2022 às 17:54, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade@gmail.com> escreveu:

 Em sáb., 14 de mai. de 2022 às 08:44, Paul Cercueil
 <paul@crapouillou.net> escreveu:
 >
 > Hi,

   Hi,

 > I'm not exactly sure what's happening, but I can get Lightning to
 > generate invalid code using jit_stxi() on PPC64.
 >
 > Here's a simple program to reproduce the issue:
 >
 > #include <lightning.h>
 >
 > int main(int argc, char **argv)
 > {
 >  jit_state_t *_jit;
 >
 >  init_jit(argv[0]);
 >  _jit = jit_new_state();
 >  jit_prolog();
 >
 >  jit_stxi(0x31a, JIT_R1, JIT_V2);
 >
 >  jit_ret();
 >  jit_epilog();
 >
 >  jit_emit();
 >  jit_disassemble();
 >
 >  jit_clear_state();
 >  jit_destroy_state();
 >  finish_jit();
 >
 >  return 0;
 > }
 >
 >
 > The disassembler will print the following:
 >     0x3fff8b230000 mflr r0
 >     0x3fff8b230004 std r0,16(r1)
 >     0x3fff8b230008 std r31,-8(r1)
 >     0x3fff8b23000c mr r31,r1
 >     0x3fff8b230010 stdu r1,-256(r1)
 >     0x3fff8b230014 .long 0xfb3d031a
 >     0x3fff8b230018 addi r1,r1,256
 >     0x3fff8b23001c ld r0,16(r1)
 >     0x3fff8b230020 mtlr r0
 >     0x3fff8b230024 ld r31,-8(r1)
 >     0x3fff8b230028 blr
 >
 >
 > Of course this program won't execute properly (since the registers
> aren't initialized), but in a real program, the ".long 0xfb3d031a" will
 > result in an "illegal instruction" error.

   Is this in an emulator or some other system? What I see is:

    0x3fffb7f10024:    mr      r31,r1
    0x3fffb7f10028:    stdu    r1,-272(r1)
 => 0x3fffb7f1002c:    stq     r24,792(r29)
    0x3fffb7f10030:    addi    r1,r1,272

 (gdb) p/x *(int*)0x3fffb7f1002c
 $1 = 0xfb3d031a

so, it should not be an invalid instruction. The ending "31a" appears to
 match the requested offset as well.

 > Cheers,
 > -Paul

  You might be getting some unaligned address fault:

(gdb) p 0x31a & 7
$3 = 2

You are totally right, I missed that. My offset calculation was wrong.

What threw me off-track is that I'd expect an unaligned access to result in a SIGBUS, not a SIGILL.

Problem resolved.

Cheers,
-Paul





reply via email to

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