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.
