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

[Bin Meng]

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

Ping?