Thanks, Tom, for looking into this. Thanks, Pedro, for the context and for planning to review it. The summary captures the motivation well. Note that intel has already posted the fundamental GPU debugging support for review https://inbox.sourceware.org/gdb-patches/20260812132805.380163-1-markus.t.metzger@intel.com/. Looking forward to receiving your feedback. --Mohamed ________________________________ From: Pedro Alves Sent: Friday, September 4, 2026 8:54 PM To: Tom Tromey ; Bouhaouel, Mohamed Cc: gdb-patches@sourceware.org ; Metzger, Markus T ; Rohr, Stephan ; eliz@gnu.org ; aburgess@redhat.com Subject: Re: [PATCH v4 00/11] Add AlwaysNonStop remote protocol extension On 2026-09-04 19:02, Tom Tromey wrote: >>>>>> Mohamed Bouhaouel 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 ________________________________________ Intel Deutschland GmbH Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany Tel: +49 (89) 99143-0 www.intel.de Managing Directors: Candice Moore, Jeffrey Schneiderman, Ramachandran Sitaraman Chairperson of the Supervisory Board: Sonja Pierer Registered Seat: Munich Commercial Register B: Amtsgericht Munich HRB 186928 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.