On Mon, Mar 28, 2022 at 5:10 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Mon, 28 Mar 2022 at 03:10, Bin Meng <bmeng...@gmail.com> wrote: > > IMHO it's too bad to just ignore this bug forever. > > > > This is a valid use case. It's not about whether we intentionally want > > to inspect the GIC register value from gdb. The case is that when > > single stepping the source codes it triggers the core dump for no > > reason if the instructions involved contain load/store to any of the > > GIC registers. > > Huh? Single-stepping the instruction should execute it inside > QEMU, which will do the load in the usual way. That should not > be going via gdbstub reads and writes.
Yes, single-stepping the instruction is executed in the vCPU context, but a gdb client sends additional commands, more than just telling QEMU to execute a single instruction. For example, the following is the sequence a gdb client sent when doing a "si": gdbstub_io_command Received: Z0,100000,4 gdbstub_io_reply Sent: OK gdbstub_io_got_ack Got ACK gdbstub_io_command Received: m18c430,4 gdbstub_io_reply Sent: ff430091 gdbstub_io_got_ack Got ACK gdbstub_io_command Received: vCont;s:p1.1;c:p1.-1 gdbstub_op_stepping Stepping CPU 0 gdbstub_op_continue_cpu Continuing CPU 1 gdbstub_op_continue_cpu Continuing CPU 2 gdbstub_op_continue_cpu Continuing CPU 3 gdbstub_hit_break RUN_STATE_DEBUG gdbstub_io_reply Sent: T05thread:p01.01; gdbstub_io_got_ack Got ACK gdbstub_io_command Received: g gdbstub_io_reply Sent: 3848ed0000000000f08fa610000000000300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f90000000030a5ec000000000034c4180000000000c9030000 gdbstub_io_got_ack Got ACK gdbstub_io_command Received: m18c434,4 gdbstub_io_reply Sent: 00e004d1 gdbstub_io_got_ack Got ACK gdbstub_io_command Received: m18c430,4 gdbstub_io_reply Sent: ff430091 gdbstub_io_got_ack Got ACK gdbstub_io_command Received: m18c434,4 gdbstub_io_reply Sent: 00e004d1 gdbstub_io_got_ack Got ACK gdbstub_io_command Received: m18c400,40 gdbstub_io_reply Sent: ff4300d1e00300f980370058000040f900a00191000040f900b00091000040f900e004911e7800f9fe0340f91e0000f9ff43009100e004d174390094bb390094 gdbstub_io_got_ack Got ACK gdbstub_io_command Received: mf9010000,4 Here "mf9010000,4" triggers the bug where 0xf9010000 is the GIC register. This is not something QEMU can ignore or control. The logic is inside the gdb client. Regards, Bin