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

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