Re: [PATCH v4 00/11] Add AlwaysNonStop remote protocol extension

[Pedro Alves <pedro@palves.net>]

On 2026-09-04 19:02, Tom Tromey wrote:
>>>>>> Mohamed Bouhaouel <mohamed.bouhaouel@intel.com> writes:
> 
>> This series introduces the AlwaysNonStop extension, enabling remote
>> stubs to declare preferable non-stop mode operation.  When advertised,
>> GDB defaults to non-stop mode.  Attempts to disable it might be rejected
>> by the stub with a descriptive error message.
> 
> One thing I don't see in the series is the motivation for this.
> It doesn't seem like something that would be useful to a user.
> 
> And if a server wants to work in all-stop-on-top-of-non-stop mode,
> I don't think there's really anything preventing that; but also this
> wouldn't require any kind of protocol extension.
> 
> I looked at this a little but I'm perhaps not the best person to review
> it.  I can take a stab at some of it at some point; but I would like to
> understand the purpose.
> 

FWIW, I discussed the design that led to this with Mohamed and others off-list,
and I do plan to review it once I'm able.  I'll try to give it a shot next week.

The main purpose is that Intel's GPU support is designed as combining two
inferiors, one for the CPU side, and one for the GPU side.  The CPU side
is a standard linux-nat target, which runs in all-stop-on-top-of-non-stop (AS-NS).
The GPU side is based on a remote gdbserver connection.

Combining a non-stop (native) with an all-stop (remote/gdbserver) target is
something that infrun is not really prepared for.  So I've suggested that instead,
it'll be better if Intel's gdbserver always works in non-stop mode, too.

There is really currently no way for the server to tell GDB that it wants to work
in that way.  Users would have to set "maint set target-non-stop on" manually.

AS-NS on the remote side has some user-visible advantages.  The AS variant of the
protocol doesn't let you talk to the remote side until the target next stops, for
example.  so no setting breakpoints, no reading global variables, etc., none of that is
possible while the target is running, while it is, in AS-NS.  The main difference
is that vCont is asynchronous in the non-stop remote protocol.  So ideally, we'd
switch over to that variant when we can, by default.  But since there are
limitations (the ones I listed in the discussion of a previous revision of this series),
a remote target reporting that is supports non-stop mode, should not be taken as meaning
that it prefers to use non-stop mode by default.  That's what the new extension gives us,
a way for the remote target to tell GDB what it wants.

I ran out of time this week, but I'll try to look at this soon.  And of course, others
shouldn't be discouraged from looking just because I said I would.  The more eyes,
the better.

Pedro Alves