Re: [PATCH 1/2] gdbstub: Set current_cpu for memory read write

[Bin Meng]

On Mon, Mar 28, 2022 at 5:10 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Mon, 28 Mar 2022 at 03:10, Bin Meng <bmeng.cn@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