Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes

[BALATON Zoltan <balaton@eik.bme.hu>]

On Wed, 26 Jun 2019, Mark Cave-Ayland wrote:
> On 26/06/2019 08:45, Richard Henderson wrote:
>> On 6/25/19 7:55 PM, Mark Cave-Ayland wrote:
>>> And here's where we are blowing up according to -d in_asm,op_out_asm:
>>>
>>> IN:
>>> 0x00f22ca0:  101ffc84  vor      v0, v31, v31
>>>
>>> OP:
>>>  ld_i32 tmp0,env,$0xfffffff8
>>>  movi_i32 tmp1,$0x0
>>>  brcond_i32 tmp0,tmp1,lt,$L0
>>>
>>>  ---- 00f22ca0
>>>  ld_vec v128,e8,tmp2,env,$0xd6b0
>>>  st_vec v128,e8,tmp2,env,$0xd4c0
>>
>> Yep, that looks right.
>>
>> As an aside, this does suggest to me that target/ppc might be well served in
>> moving the ppc_vsr_t members of CPUPPCState earlier, so that this offset is
>> smaller.
>>
>>>  movi_i32 nip,$0xf22ca4
>>>  movi_i32 nip,$0xf22ca4
>>>  movi_i32 tmp0,$0x10002
>>>  call raise_exception,$0x2,$0,env,tmp0
>>
>> And this, presumably is the single-step debug exception.
>>
>>> 0xa4e7f12c:  3c400000  lis      r2, 0
>>> 0xa4e7f130:  6042d6b0  ori      r2, r2, 0xd6b0
>>> 0xa4e7f134:  7c5b10ce  lvx      v2, r27, r2
>>
>>> 0xa4e7f138:  3c400000  lis      r2, 0
>>> 0xa4e7f13c:  6042d4c0  ori      r2, r2, 0xd4c0
>>> 0xa4e7f140:  7c5b11ce  stvx     v2, r27, r2
>>
>> These also look correct.  Form an offset into r2, load or store from env+r2.
>>
>> This also shows what I mention above re offset.  For a ppc host, the offset is
>> large enough to require two instructions to form them.
>>
>>> Any ideas what might be going on here?
>>
>> What is the observed problem that makes you think that this is the incorrect
>> instruction?
>
> What I've been doing is set a breakpoint a few instructions before and then issuing
> "stepi" commands via the gdbstub. As I step over the "vor v0, v31, v31" instruction
> then either the qemu-system-ppc process segfaults outside of gdb, or inside gdb it
> goes to bg. Bringing it back to fg just causes gdb to get confused and in the end the
> only thing I can do is kill the gdb process.
>
> On the plus side I've managed to work out where we are faulting by hacking the load
> and store functions to inject trap opcodes in the ld_vec and st_vec and it appears
> that we are segfaulting here:
>
> OUT: [size=96]
> 0xa4e7f120:  81dbfff8  lwz      r14, -8(r27)
> 0xa4e7f124:  2f8e0000  cmpwi    cr7, r14, 0
> 0xa4e7f128:  419c004c  blt      cr7, 0xa4e7f174
> 0xa4e7f12c:  3c400000  lis      r2, 0
>                       ^^^^^^^^^^^^^^
> 0xa4e7f130:  6042d6b0  ori      r2, r2, 0xd6b0
> 0xa4e7f134:  7c5b10ce  lvx      v2, r27, r2
> 0xa4e7f138:  3c400000  lis      r2, 0
> 0xa4e7f13c:  6042d4c0  ori      r2, r2, 0xd4c0
> 0xa4e7f140:  7c5b11ce  stvx     v2, r27, r2
> 0xa4e7f144:  3dc000f2  lis      r14, 0xf2
> 0xa4e7f148:  61ce2ca4  ori      r14, r14, 0x2ca4
> 0xa4e7f14c:  91db016c  stw      r14, 0x16c(r27)
> 0xa4e7f150:  7f63db78  mr       r3, r27
> 0xa4e7f154:  3c800001  lis      r4, 1
> 0xa4e7f158:  60840002  ori      r4, r4, 2
> 0xa4e7f15c:  3c000087  lis      r0, 0x87
> 0xa4e7f160:  6000b618  ori      r0, r0, 0xb618
> 0xa4e7f164:  7c0903a6  mtctr    r0
> 0xa4e7f168:  4e800421  bctrl
> 0xa4e7f16c:  38600000  li       r3, 0
> 0xa4e7f170:  4bfffef0  b        0xa4e7f060
> 0xa4e7f174:  3c60a4e7  lis      r3, -0x5b19
> 0xa4e7f178:  6063f0c3  ori      r3, r3, 0xf0c3
> 0xa4e7f17c:  4bfffee4  b        0xa4e7f060
>
> Interestingly if I set a trap and then switch the opcode to "lis r4,0" (0x3c800000)
> then we carry on as normal until the next "lis r2,0" instruction. Looking through the
> whole output of -d out_asm this is the first mention of r2 which makes me wonder if
> it is special somehow? At least a quick search indicates that for 32-bit PPC r2 is
> supposed to be dedicated as a TOC pointer.

According to a PowerPC ABI doc: 
http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf
r2 is system reserved and should not be used by application code and 
another one (probably the same you were referring to mentions TOC 
https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#REG. 
I'm not sure if that's relevant for the above but it looks like clobbering 
r2 might cause problems.

Regards,
BALATON Zoltan