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