SIGSEGV when reading ARM GIC registers through GDB stub

[Luc Michel]

When trying to access ARM GIC CPU registers through a target GDB connected to QEMU, QEMU crashes with a SIGSEGV.

Reproducible on last master revision (74e1b78 at the time of writing):

$ ./configure --target-list=arm-softmmu --python=python2 --enable-debug
$ make
$ gdb --args ./arm-softmmu/qemu-system-arm -M vexpress-a15 -smp 2 -s -S

Connect a gdb on the other side:
$ arm-none-eabi-gdb
(gdb) tar rem :1234
Remote debugging using :1234
0x00000000 in ?? ()
(gdb) x /x 0x2c002000

QEMU crashes as it tries to access current_cpu->cpu_index while current_cpu is NULL:

Thread 1 "qemu-system-arm" received signal SIGSEGV, Segmentation fault.
0x0000555555a372cf in gic_get_current_cpu (s=0x555556a34f10) at hw/intc/arm_gic.c:53
53 return current_cpu->cpu_index;
(gdb) p current_cpu
$1 = (CPUState *) 0x0

Backtrace:
(gdb) bt
#0 0x0000555555a372cf in gic_get_current_cpu (s=0x555556a34f10) at hw/intc/arm_gic.c:53
#1 0x0000555555a3b0e3 in gic_thiscpu_read (opaque=0x555556a34f10, addr=0, data=0x7fffffffa0a8, size=4, attrs=...) at hw/intc/arm_gic.c:1340
#2 0x00005555557ae2bb in memory_region_read_with_attrs_accessor (mr=0x555556a37a70, addr=0, value=0x7fffffffa208, size=4, shift=0, mask=4294967295, attrs=...) at /home/sekoia/devel/src/qemu/memory.c:461
#3 0x00005555557ae7ac in access_with_adjusted_size (addr=0, value=0x7fffffffa208, size=4, access_size_min=1, access_size_max=4, access=0x5555557ae25f <memory_region_read_with_attrs_accessor>, mr=0x555556a37a70, attrs=...)
    at /home/sekoia/devel/src/qemu/memory.c:591
#4 0x00005555557b0de7 in memory_region_dispatch_read1 (mr=0x555556a37a70, addr=0, pval=0x7fffffffa208, size=4, attrs=...) at /home/sekoia/devel/src/qemu/memory.c:1187
#5 0x00005555557b0e9d in memory_region_dispatch_read (mr=0x555556a37a70, addr=0, pval=0x7fffffffa208, size=4, attrs=...) at /home/sekoia/devel/src/qemu/memory.c:1212
#6 0x000055555576775b in address_space_read_continue (as=0x5555569c70b0, addr=738205696, attrs=..., buf=0x7fffffffb440 "", len=4, addr1=0, l=4, mr=0x555556a37a70) at /home/sekoia/devel/src/qemu/exec.c:2668
#7 0x0000555555767929 in address_space_read_full (as=0x5555569c70b0, addr=738205696, attrs=..., buf=0x7fffffffb440 "", len=4) at /home/sekoia/devel/src/qemu/exec.c:2725
#8 0x00005555557679eb in address_space_read (len=4, buf=0x7fffffffb440 "", attrs=..., addr=738205696, as=0x5555569c70b0) at /home/sekoia/devel/src/qemu/include/exec/memory.h:1476
#9 address_space_rw (as=0x5555569c70b0, addr=738205696, attrs=..., buf=0x7fffffffb440 "", len=4, is_write=false) at /home/sekoia/devel/src/qemu/exec.c:2739
#10 0x000055555576988f in cpu_memory_rw_debug (cpu=0x5555568a3d00, addr=738205696, buf=0x7fffffffb440 "", len=4, is_write=0) at /home/sekoia/devel/src/qemu/exec.c:3653
#11 0x00005555557a3db3 in target_memory_rw_debug (cpu=0x5555568a3d00, addr=738205696, buf=0x7fffffffb440 "", len=4, is_write=false) at /home/sekoia/devel/src/qemu/gdbstub.c:54
#12 0x00005555557a53f5 in gdb_handle_packet (s=0x55555722c530, line_buf=0x55555722c54c "m2c002000,4") at /home/sekoia/devel/src/qemu/gdbstub.c:968
#13 0x00005555557a6b84 in gdb_read_byte (s=0x55555722c530, ch=52) at /home/sekoia/devel/src/qemu/gdbstub.c:1458
#14 0x00005555557a6ca4 in gdb_chr_receive (opaque=0x0, buf=0x7fffffffc590 "$m2c002000,4#84c8ead:arm-neon.xml:7fd,802#4c;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df", size=15)
    at /home/sekoia/devel/src/qemu/gdbstub.c:1666
#15 0x000055555591c562 in qemu_chr_be_write_impl (s=0x555557226e20, buf=0x7fffffffc590 "$m2c002000,4#84c8ead:arm-neon.xml:7fd,802#4c;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df",
    len=15) at qemu-char.c:387
#16 0x000055555591c5c0 in qemu_chr_be_write (s=0x555557226e20, buf=0x7fffffffc590 "$m2c002000,4#84c8ead:arm-neon.xml:7fd,802#4c;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df", len=15)
    at qemu-char.c:399
#17 0x00005555559207f3 in tcp_chr_read (chan=0x555556e52ff0, cond=G_IO_IN, opaque=0x555557226e20) at qemu-char.c:2893
#18 0x0000555555c4a9b7 in qio_channel_fd_source_dispatch (source=0x555557226ca0, callback=0x55555592069d <tcp_chr_read>, user_data=0x555557226e20) at io/channel-watch.c:84
#19 0x00007fffed977c8a in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#20 0x0000555555bbf711 in glib_pollfds_poll () at main-loop.c:213
#21 0x0000555555bbf7ec in os_host_main_loop_wait (timeout=29744918) at main-loop.c:258
#22 0x0000555555bbf899 in main_loop_wait (nonblocking=0) at main-loop.c:506
#23 0x0000555555929cd2 in main_loop () at vl.c:1908
#24 0x00005555559315b7 in main (argc=8, argv=0x7fffffffdae8, envp=0x7fffffffdb30) at vl.c:4604

Note that this bug is triggered only when the number of simulated CPUs is greater than 1.

[Peter Maydell (pmaydell)]

This happens because although the gdbstub tells the memory system which CPU it wants to perform the access as, this gets lost in cpu_memory_rw_debug(), which doesn't set current_cpu. I'm not sure if we could get away with just doing that at that point: I wouldn't be surprised if that would break other things.

Ideally we'd have a better mechanism for devices which care about which CPU was doing the access to work than looking at current_cpu.

[Peter Maydell (pmaydell)]

See also LP:1751674 -- similar crash trying to access the GICv2 per-cpu regs from the QEMU monitor's pmemsave command.

[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/124