On Sat, Apr 2, 2022 at 7:20 PM Bin Meng <bmeng...@gmail.com> wrote: > > On Tue, Mar 29, 2022 at 12:43 PM Bin Meng <bmeng...@gmail.com> wrote: > > > > 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. > > > > Ping for this series? >
Ping?
