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? r~
