GDB context is inconsistent after "monitor system_reset"

[Sebastian Huber]

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

[Thomas Huth (th-huth)]

Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?

[Sebastian Huber (sebastian-huber)]

With this Qemu:

qemu-system-arm --version
QEMU emulator version 4.2.50 (v4.2.0-1276-g863d2ed582)
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers

I still have the same issue:

(gdb) info registers
r0 0x0 0
r1 0x9010001 151060481
r2 0x0 0
r3 0x428c89 4361353
r4 0x640f08 6557448
r5 0x672480 6759552
r6 0x0 0
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x60bb80 6339456
sp 0x6783f0 0x6783f0 <_Thread_Idle_stacks+4080>
lr 0x425fa1 4349857
pc 0x428c8a 0x428c8a <_CPU_Thread_Idle_body+2>
cpsr 0x60070173 1611071859
fpscr 0x0 0
fpsid 0x41033090 1090728080
fpexc 0x40000000 1073741824
[...]
(gdb) monitor info registers
R00=00000000 R01=09010001 R02=00000000 R03=00428c89
R04=00640f08 R05=00672480 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=0060bb80 R13=006783f0 R14=00425fa1 R15=00428c8a
PSR=60070173 -ZC- T svc32
s00=00013831 s01=00000000 d00=0000000000013831
s02=00000e0f s03=00000000 d01=0000000000000e0f
s04=00000000 s05=00000000 d02=0000000000000000
s06=00000000 s07=00000000 d03=0000000000000000
s08=00000000 s09=00000000 d04=0000000000000000
s10=00000000 s11=00000000 d05=0000000000000000
s12=00000000 s13=00000000 d06=0000000000000000
s14=00000000 s15=00000000 d07=0000000000000000
s16=00000000 s17=00000000 d08=0000000000000000
s18=00000000 s19=00000000 d09=0000000000000000
s20=00000000 s21=00000000 d10=0000000000000000
s22=00000000 s23=00000000 d11=0000000000000000
s24=00000000 s25=00000000 d12=0000000000000000
s26=00000000 s27=00000000 d13=0000000000000000
s28=00000000 s29=00000000 d14=0000000000000000
s30=00000000 s31=00000000 d15=0000000000000000
s32=00000000 s33=00000000 d16=0000000000000000
s34=00000000 s35=00000000 d17=0000000000000000
s36=00000000 s37=00000000 d18=0000000000000000
s38=00000000 s39=00000000 d19=0000000000000000
s40=00000000 s41=00000000 d20=0000000000000000
s42=00000000 s43=00000000 d21=0000000000000000
s44=00000000 s45=00000000 d22=0000000000000000
s46=00000000 s47=00000000 d23=0000000000000000
s48=00000000 s49=00000000 d24=0000000000000000
s50=00000000 s51=00000000 d25=0000000000000000
s52=00000000 s53=00000000 d26=0000000000000000
s54=00000000 s55=00000000 d27=0000000000000000
s56=00000000 s57=00000000 d28=0000000000000000
s58=00000000 s59=00000000 d29=0000000000000000
s60=00000000 s61=00000000 d30=0000000000000000
s62=00000000 s63=00000000 d31=0000000000000000
FPSCR: 00000000
(gdb) monitor system_reset
(gdb) info registers
r0 0x0 0
r1 0x9010001 151060481
r2 0x0 0
r3 0x428c89 4361353
r4 0x640f08 6557448
r5 0x672480 6759552
r6 0x0 ...

[Sebastian Huber (sebastian-huber)]

I can also build the latest Git master of Qemu if this helps.

[Peter Maydell (pmaydell)]

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...

[Thomas Huth (th-huth)]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/100