gdbstub.c CPU clusters not handled for ThreadInfo packets

gdbstub.c CPU clusters not handled for ThreadInfo packets

[Fabien Chouteau]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

Hi all,

(Luc, I am putting in copy because from the logs it looks like you
implemented the multiprocess support)

Using the sifive_u machine on qemu-system-riscv64 which has 2 clusters of 1
and 4 CPUs respectively, when I use the "info threads" command in GDB only
one thread is displayed.
This thread is the only CPU of the 1st cluster, the CPUs of cluster 2nd are
not listed at all.

Looking at the GDB remote packets (see below) we can see that indeed only
one thread is listed (mp01.01). It seems to me that the functions
handle_query_first_threads() and handle_query_threads() of gdbstub.c are
not handling the new multiprocess implementation. I would like to fix it
but I am lost between cpus, processes, threads, etc.

Does anyone have an idea how to fix this?

Regards,

(gdb) info threads
Sending packet: $qfThreadInfo#bb...Ack
Packet received: mp01.01
Sending packet: $qsThreadInfo#c8...Ack
Packet received: l
Sending packet: $qThreadExtraInfo,p1.1#85...Ack
Packet received:
7369666976652d6535312d72697363762d6370752068617274735b305d205b72756e6e696e675d
  Id   Target Id                                            Frame
* 1    Thread 1.1 (sifive-e51-riscv-cpu harts[0] [running])
0x0000000000001000 in ?? ()
(gdb)

[-- Attachment #2: Type: text/html, Size: 1498 bytes --]

Re: gdbstub.c CPU clusters not handled for ThreadInfo packets

[Peter Maydell]

On Tue, 2 Jun 2020 at 17:25, Fabien Chouteau <chouteau@adacore.com> wrote:
> Using the sifive_u machine on qemu-system-riscv64 which has 2 clusters of 1 and 4 CPUs respectively, when I use the "info threads" command in GDB only one thread is displayed.
> This thread is the only CPU of the 1st cluster, the CPUs of cluster 2nd are not listed at all.

By default gdb does not attach to all clusters (this is IIRC something
that can't
be influenced on the QEMU end); are you explicitly asking it to attach to the
second cluster?

https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg07035.html
is a mailing list post from January which gives the gdb commands which
ought to cause it to attach to the second cluster on this machine.

thanks
-- PMM

Re: gdbstub.c CPU clusters not handled for ThreadInfo packets

[Fabien Chouteau]

Thank you Peter,

Le mar. 2 juin 2020 à 18:44, Peter Maydell <peter.maydell@linaro.org> a écrit :
>
> By default gdb does not attach to all clusters (this is IIRC something
> that can't
> be influenced on the QEMU end);

You mean I cannot have QEMU attach all clusters by default?

> are you explicitly asking it to attach to the second cluster?

So far the behavior that we had was to see all the CPUs without asking
explicitly.
I want to go back to that behavior because the current situation is a
huge drawback for our users.

> https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg07035.html
> is a mailing list post from January which gives the gdb commands which
> ought to cause it to attach to the second cluster on this machine.

The commands:
        target extended-remote :1234
        add-inferior
        inferior 2
        attach 2
        set schedule-multiple
        info threads

Do not work for me, "attach 2" in GDB asks me to kill the debugged program.

Thanks for your help,

Re: gdbstub.c CPU clusters not handled for ThreadInfo packets

[Peter Maydell]

On Tue, 2 Jun 2020 at 18:19, Fabien Chouteau <chouteau@adacore.com> wrote:
> Le mar. 2 juin 2020 à 18:44, Peter Maydell <peter.maydell@linaro.org> a écrit :
> >
> > By default gdb does not attach to all clusters (this is IIRC something
> > that can't
> > be influenced on the QEMU end);
>
> You mean I cannot have QEMU attach all clusters by default?

I mean that the end of the gdb remote protocol connection that
decides what to attach to is gdb, not QEMU. In theory gdb could
be improved to automatically attach to all available inferiors,
or the remote protocol could be improved to allow the QEMU end
to say "I recommend you attach to inferiors X, Y and Z". But
at the moment that doesn't exist so the best you can do I suspect
is going to be to script gdb to do the attaching without you
having to type the commands yourself.

> > are you explicitly asking it to attach to the second cluster?
>
> So far the behavior that we had was to see all the CPUs without asking
> explicitly.
> I want to go back to that behavior because the current situation is a
> huge drawback for our users.

That works when there's only one cluster. When there's multiple
clusters, by default gdb will show you all the CPUs in the first
cluster. Would the behaviour be better if the other cluster in
this machine was the first (default) one?

> > https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg07035.html
> > is a mailing list post from January which gives the gdb commands which
> > ought to cause it to attach to the second cluster on this machine.
>
> The commands:
>         target extended-remote :1234
>         add-inferior
>         inferior 2
>         attach 2
>         set schedule-multiple
>         info threads
>
> Do not work for me, "attach 2" in GDB asks me to kill the debugged program.

Hmm. That's the behavior for 'target remote' but 'target extended-remote'
ought to support multiple inferiors. What gdb version is this?

thanks
-- PMM

Re: gdbstub.c CPU clusters not handled for ThreadInfo packets

[Alistair Francis]

On Tue, Jun 2, 2020 at 10:27 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Tue, 2 Jun 2020 at 18:19, Fabien Chouteau <chouteau@adacore.com> wrote:
> > Le mar. 2 juin 2020 à 18:44, Peter Maydell <peter.maydell@linaro.org> a écrit :
> > >
> > > By default gdb does not attach to all clusters (this is IIRC something
> > > that can't
> > > be influenced on the QEMU end);
> >
> > You mean I cannot have QEMU attach all clusters by default?
>
> I mean that the end of the gdb remote protocol connection that
> decides what to attach to is gdb, not QEMU. In theory gdb could
> be improved to automatically attach to all available inferiors,
> or the remote protocol could be improved to allow the QEMU end
> to say "I recommend you attach to inferiors X, Y and Z". But
> at the moment that doesn't exist so the best you can do I suspect
> is going to be to script gdb to do the attaching without you
> having to type the commands yourself.
>
> > > are you explicitly asking it to attach to the second cluster?
> >
> > So far the behavior that we had was to see all the CPUs without asking
> > explicitly.
> > I want to go back to that behavior because the current situation is a
> > huge drawback for our users.
>
> That works when there's only one cluster. When there's multiple
> clusters, by default gdb will show you all the CPUs in the first
> cluster. Would the behaviour be better if the other cluster in
> this machine was the first (default) one?
>
> > > https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg07035.html
> > > is a mailing list post from January which gives the gdb commands which
> > > ought to cause it to attach to the second cluster on this machine.
> >
> > The commands:
> >         target extended-remote :1234
> >         add-inferior
> >         inferior 2
> >         attach 2
> >         set schedule-multiple
> >         info threads

I just updated the QEMU RISC-V wiki to include these steps:

https://wiki.qemu.org/Documentation/Platforms/RISCV#Attaching_GDB

Alistair

> >
> > Do not work for me, "attach 2" in GDB asks me to kill the debugged program.
>
> Hmm. That's the behavior for 'target remote' but 'target extended-remote'
> ought to support multiple inferiors. What gdb version is this?
>
> thanks
> -- PMM
>

Re: gdbstub.c CPU clusters not handled for ThreadInfo packets

[Fabien Chouteau]

On Tue, Jun 2, 2020 at 7:26 PM Peter Maydell <peter.maydell@linaro.org> wrote:
> When there's multiple clusters, by default gdb will show you all the CPUs in the first
> cluster. Would the behaviour be better if the other cluster in
> this machine was the first (default) one?

For our use case yes it would be better. I will look to see if this is
doable with a small patch on our fork.

> Hmm. That's the behavior for 'target remote' but 'target extended-remote'
> ought to support multiple inferiors. What gdb version is this?

Force of habit, I made a fool of myself and used only 'target remote'.
Sorry for the noise here.

Thanks for your help,