On Fri, Oct 16, 2015 at 10:37 AM, Peter Maydell
<peter.mayd...@linaro.org> wrote:
> It would be helpful if you said what the abort actually was
> (ie what instruction do we abort on, what are the fault status/
> fault address registers if applicable, etc).
I should have been more specific. Running trunk qemu on the patched
zImage with qemu-system-arm -M vexpress-a9 -kernel
linux/arch/arm/boot/zImage -serial stdio -dtb
linux/arch/arm/boot/dts/vexpress-v2p-ca9.dtb -s -S then attaching gdb
generates the following information. I haven't nailed the actual
instruction causing the abort yet. Is it obvious from the registers?
(gdb) target remote :1234
Remote debugging using :1234
0x60000000 in ?? ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
__vectors_start () at arch/arm/kernel/entry-armv.S:1240
1240 W(b) vector_pabt
(gdb) info registers
r0 0xc5507d 12931197
r1 0xfffffffd -3
r2 0x600 1536
r3 0xffffc000 -16384
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x8e0 2272
r8 0x64000000 1677721600
r9 0xfffc0000 -262144
r10 0xffc0000 268173312
r11 0x100103 1048835
r12 0x600100c8 1610678472
sp 0x0 0x0 <__vectors_start>
lr 0x10 16
pc 0xc 0xc <__vectors_start+12>
cpsr 0x1d7 471
(gdb)
Did it abort at 0x600100c8?
(gdb) disassemble 0x60010000,+1024
Dump of assembler code from 0x60010000 to 0x60010400:
0x60010000: nop ; (mov r0, r0)
0x60010004: nop ; (mov r0, r0)
0x60010008: nop ; (mov r0, r0)
0x6001000c: nop ; (mov r0, r0)
0x60010010: nop ; (mov r0, r0)
0x60010014: nop ; (mov r0, r0)
0x60010018: nop ; (mov r0, r0)
0x6001001c: nop ; (mov r0, r0)
0x60010020: b 0x60010034
0x60010024: cmneq pc, r8, lsl r8 ; <UNPREDICTABLE>
0x60010028: andeq r0, r0, r0
0x6001002c: eorseq r4, r4, r8, asr pc
0x60010030: streq r0, [r3], #-513 ; 0xfffffdff
0x60010034: mrs r9, CPSR
0x60010038: bl 0x60013560
0x6001003c: mov r7, r1
0x60010040: mov r8, r2
0x60010044: mrs r2, CPSR
0x60010048: tst r2, #3
0x6001004c: bne 0x60010058
0x60010050: mov r0, #23
0x60010054: svc 0x00123456
0x60010058: mrs r0, CPSR
0x6001005c: eor r0, r0, #26
0x60010060: tst r0, #31
0x60010064: bic r0, r0, #31
0x60010068: orr r0, r0, #211 ; 0xd3
0x6001006c: bne 0x60010084
0x60010070: orr r0, r0, #256 ; 0x100
0x60010074: add lr, pc, #12
0x60010078: msr SPSR_fsxc, r0
0x6001007c: msr ELR_hyp, lr
0x60010080: eret
0x60010084: msr CPSR_c, r0
0x60010088: msr SPSR_fsxc, r9
0x6001008c: andeq r0, r0, r0
0x60010090: andeq r0, r0, r0
0x60010094: andeq r0, r0, r0
0x60010098: andeq r0, r0, r0
0x6001009c: andeq r0, r0, r0
0x600100a0: mov r4, pc
0x600100a4: and r4, r4, #-134217728 ; 0xf8000000
0x600100a8: add r4, r4, #32768 ; 0x8000
0x600100ac: mov r0, pc
0x600100b0: cmp r0, r4
0x600100b4: ldrcc r0, [pc, #428] ; 0x60010268
0x600100b8: addcc r0, r0, pc
0x600100bc: cmpcc r4, r0
0x600100c0: orrcc r4, r4, #1
0x600100c4: blcs 0x60010280
0x600100c8: add r0, pc, #376 ; 0x178
0x600100cc: ldm r0, {r1, r2, r3, r6, r10, r11, r12}
0x600100d0: ldr sp, [r0, #28]
>
> (I assume you mean "we send an abort to the guest", not "QEMU's
> C code calls abort(); if the latter, please provide a backtrace.)
>
Right, this is way before the kernel is even decompressed, QEMU sends
a CPU abort to the guest, QEMU itself does not crash
