I suspect that gdb has cached the values of the registers and we haven't done anything to tell it that they're now stale. I'm not sure the gdbstub protocol even has a mechanism for doing this -- after all, from gdb's point of view the target is stopped and it does not expect that its state will change until gdb asks it to resume execution.
I'm not sure how this could be dealt with -- in theory one could forbid actions like system reset while the gdbstub had control, but that seems likely to have unwelcome side-effects... -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1277433 Title: GDB context is inconsistent after "monitor system_reset" Status in QEMU: Incomplete Bug description: After a "monitor system_reset" the GDB view to the system state differs from QEMUs processor state. Breakpoint 8, _ARMV4_Exception_interrupt () at /home/sh/rtems-4.11/c/src/../../cpukit/score/cpu/arm/arm_exc_interrupt.S:74 74 mov EXCHANGE_LR, lr (gdb) info registers r0 0x2027e8 2107368 r1 0x204208 2114056 r2 0x13 19 r3 0x204238 2114104 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 sp 0x201480 0x201480 lr 0x110958 1116504 pc 0x11073c 0x11073c <_ARMV4_Exception_interrupt+4> cpsr 0x192 402 (gdb) monitor info registers R00=002027e8 R01=00204208 R02=00000013 R03=00204238 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=00201480 R14=00110958 R15=0011073c PSR=00000192 ---- A irq32 (gdb) monitor system_reset (gdb) info registers r0 0x2027e8 2107368 r1 0x204208 2114056 r2 0x13 19 r3 0x204238 2114104 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 sp 0x201480 0x201480 lr 0x110958 1116504 pc 0x11073c 0x11073c <_ARMV4_Exception_interrupt+4> cpsr 0x192 402 (gdb) monitor info registers R00=00000000 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=00000000 R14=00000000 R15=00100040 PSR=400001d3 -Z-- A svc32 Why does the second "info registers" and "monitor info registers" differ? After a single instruction step they are synchronized at least on ARM (on SPARC this is different). (gdb) si bsp_start_vector_table_end () at /home/sh/rtems-4.11/c/src/lib/libbsp/arm/realview-pbx-a9/../shared/start/start.S:144 144 msr cpsr, r0 (gdb) info registers r0 0xd3 211 r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 sp 0x0 0x0 lr 0x0 0 pc 0x100044 0x100044 <bsp_start_vector_table_end+4> cpsr 0x400001d3 1073742291 (gdb) monitor info registers R00=000000d3 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=00000000 R14=00000000 R15=00100044 PSR=400001d3 -Z-- A svc32 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1277433/+subscriptions
