Re: [PATCH] ppc: Fix 'calli' when floating-point arguments are passed

[Paulo César Pereira de Andrade]

Em sex., 9 de set. de 2022 às 10:21, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade@gmail.com> escreveu:
>
> Em sex., 9 de set. de 2022 às 07:01, Paul Cercueil
> <paul@crapouillou.net> escreveu:
> >
> > Hi Paulo,
>
>   Hi Paul,
>
> > Le jeu., sept. 8 2022 at 17:33:22 -0300, Paulo César Pereira de
> > Andrade <paulo.cesar.pereira.de.andrade@gmail.com> a écrit :
> > > Em qui., 8 de set. de 2022 às 16:00, Paul Cercueil
> > > <paul@crapouillou.net> escreveu:
> > >
> > >   Hi Paul,
> > >
> > >>  Le jeu., sept. 8 2022 at 14:52:28 -0300, Paulo César Pereira de
> > >>  Andrade <paulo.cesar.pereira.de.andrade@gmail.com> a écrit :
> > >>  > Em qui., 8 de set. de 2022 às 14:18, Paulo César Pereira de
> > >> Andrade
> > >>  > <paulo.cesar.pereira.de.andrade@gmail.com> escreveu:
> > >>  >
> > >>  > [snip]
> > >>  >
> > >>  >>  > The problem now is that r26 should be live at L2 but is not
> > >>  >> detected as
> > >>  >>  > such.
> > >>  >>  > This causes Lightning to use r26 as a temporary for the andi
> > >> line
> > >>  >> 34
> > >>  >>  > (lines 153-155 in the generated code).
> > >>  >>
> > >>  >>    What code you use to access 'r10' and 'r3'? It is possible to
> > >> use
> > >>  >>  JIT_R(5) and JIT_R(12) as I did in the C code, but it is an ugly
> > >>  >> hack,
> > >>  >>  taking advantage that it does not check bounds. The
> > >>  >> check/lightning.c
> > >>  >>  code need to be patched to accept it...
> > >>  >>
> > >>  >>    Can you create a reproducer in C, starting with the above
> > >> sample?
> > >>  >
> > >>  >   Well, the most likely cause is that it did happen because of a
> > >>  > lightning
> > >>  > build without the last 3 commits, and is a side effect of the
> > >> jumps
> > >>  > to a
> > >>  > raw address:
> > >>  >
> > >>  >     jmpi 0x20000d0c
> > >>
> > >>  I can assure you I triple-checked that. I removed the library in my
> > >>  toolchain, my program would complain that liblightning.so.0 is
> > >> missing,
> > >>  then I just "make clean install" with the proper path, my program
> > >> picks
> > >>  up the library just fine. And I'm at the latest origin/master,
> > >> clean,
> > >>  no local changes. Also, others can reproduce my issue with my
> > >> program +
> > >>  Lightning master.
> > >>
> > >>  Now what's really triggering me, is that I have a C program that
> > >>  produces the *exact* same Lightning output (see attachment). It is
> > >>  exactly the same, the *only* differences are the jmpi addresses,
> > >> and my
> > >>  test program does not have the r26 missing in L2.
> > >>
> > >>  So even with the exact same code in a test example, I cannot
> > >> reproduce
> > >>  it. Yet my regular program shows the bug with the exact same
> > >> Lightning
> > >>  calls. I have absolutely no idea what's going on.
> > >
> > >   Please try this:
> >
> > [snip]
> >
> > So I tried following your instructions. Attached is my GDB log.
> >
> > As you can see from the log… The bit 17 was never set.
> >
> > Do any of these values make sense to you?
>
>   It must be set as live at the start of the block in the first store
>
>     jit_stxi_i(0x3e7c, JIT_R1, JIT_V1);
>
> This is in the simple path. The other stores do nothing as it is already
> marked as live.
>
> > The very last break happened as it was calling jit_new_state() again,
> > so I suppose the memory address that was being watched was being reused
> > and I stopped the debugging session there.
>
>   Please just do call jit_print() after finishing split_branches, for example:
>
> Breakpoint 1, _split_branches (_jit=0x10111270) at lightning.c:2713
> 2713        for (node = _jitc->head; node; node = next) {
> (gdb) call _jit_print(_jit)
> L0: /* prolog */
>     #name
>     #note 395
> ...
>
> and let me know the output. The likely explanation for it not being set,
> assuming lightning code is not modified, is that there is some extra
> code changing the value of r26 after it is used as a temporary. Something
> like in the range from "L2:" to the "stxi_i 0x3e7c r29 r26" below, there is
> some instruction that changes r26, and causes it to assume it is dead in
> that range, and usable as a temporary.
>
> L2:
>     #name
>     movi r27 0x70
>     stxi_i 0x8 r14 r27
>     #name
>     #note 584
>     movi r27 0x800c0000
>     #name
>     #note 1248
>     andi r30 r27 0x7fffff
>     addi r29 r30 0x10000000
>     stxi_i 0x3e7c r29 r26
>
> The jit_print() call will not crash at that point, just print incomplete
> information, but enough to check if there is some extra instruction
> changing r26.

  You might also experiment with something bogus, like adding a:

jit_movr_d(JIT_F0, JIT_F1);

in different places, and check if the bug goes away. If that happens,
we will know there is some error, possibly some off by one somewhere,
and the small change hides it.

> > > It is very strange that only a single bit is modified, and does not
> > > look
> > > like corruption or use after free.
> > >
> > > It might be required for you to provide me with ssh access to a debug
> > > environment, but for the moment lets have a better idea of the problem
> > > based on the backtrace.
> > >
> > >>  -Paul
> > >
> > > Thanks,
> > > Paulo
> >
> > Cheers,
> > -Paul
>
> Thanks,
> Paulo