summary refs log tree commit diff stats
path: root/results/classifier/118/all/1277433
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/118/all/1277433')
-rw-r--r--results/classifier/118/all/1277433293
1 files changed, 293 insertions, 0 deletions
diff --git a/results/classifier/118/all/1277433 b/results/classifier/118/all/1277433
new file mode 100644
index 000000000..533d7bece
--- /dev/null
+++ b/results/classifier/118/all/1277433
@@ -0,0 +1,293 @@
+peripherals: 0.995
+graphic: 0.986
+permissions: 0.985
+hypervisor: 0.985
+socket: 0.982
+device: 0.981
+assembly: 0.981
+semantic: 0.981
+files: 0.979
+vnc: 0.977
+debug: 0.977
+VMM: 0.976
+TCG: 0.976
+architecture: 0.976
+arm: 0.975
+register: 0.975
+performance: 0.972
+user-level: 0.971
+mistranslation: 0.971
+PID: 0.967
+ppc: 0.965
+risc-v: 0.962
+KVM: 0.958
+virtual: 0.937
+boot: 0.937
+kernel: 0.925
+i386: 0.925
+x86: 0.924
+network: 0.904
+
+GDB context is inconsistent after "monitor system_reset"
+
+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
+
+Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+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                 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=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=00104040
+PSR=400001d3 -Z-- A svc32
+s00=00000000 s01=00000000 d00=0000000000000000
+s02=00000000 s03=00000000 d01=0000000000000000
+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) si
+bsp_start_vector_table_end () at /home/EB/sebastian_h/src/rtems/bsps/arm/shared/start/start.S:166
+166             mov     r6, r2          /* physical address of ATAGs or DTB */
+(gdb) info registers
+r0             0x0                 0
+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             0x104044            0x104044 <bsp_start_vector_table_end+4>
+cpsr           0x400001d3          1073742291
+fpscr          0x0                 0
+fpsid          0x41033090          1090728080
+fpexc          0x0                 0
+[...]
+
+I can also build the latest Git master of Qemu if this helps.
+
+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...
+
+
+
+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
+
+