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

[Paul Cercueil]

Hi Paulo,

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?

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.


> 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

gdb.txt
Description: Text document