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? Regards, Bin
