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

[Mark Cave-Ayland]

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.

Is there a quick way to disable r2 from the list of available registers to see 
if
that gets things going?


ATB,

Mark.