On 25 November 2011 15:35, Max Filippov <jcmvb...@gmail.com> wrote:
>> Breakpoint 7, cpu_arm_exec (env=0x102033200) at ~/qemu-0.15.0/cpu-exec.c:557
>> 557 next_tb = tcg_qemu_tb_exec(env, tc_ptr);
>> (gdb) p/x env->regs
>> $13 = {0x4002c00c, 0x20, 0x4, 0x0, 0x0, 0x0, 0x40000, 0x0, 0x0, 0x0, 0x0,
>> 0x0, 0x30, 0x10007fa8, 0x560d, 0x560c}
>> (gdb) s
>> 558 if ((next_tb & 3) == 2) {
>> (gdb) p/x env->regs
>> $14 = {0x10048000, 0x20, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> 0x30, 0x10007fb8, 0x560d, 0x0}
>>
>> How to check access to unallocated memory? It's not seg faulting.
>
> 290 0000042c <_init>:
> 291 42c: b5f8 push {r3, r4, r5, r6, r7, lr}
>
> set breakpoint here and see with x/6wx $sp whether saved register values are
> good.
To clarify this a bit: that means "set a breakpoint in an ARM gdb attached
to qemu's gdb-stub interface". That gdb will see the view of the guest
CPU, whereas connecting an x86 gdb directly to qemu you're looking at
qemu's internal data structures, which can be more confusing.
-- PMM
