From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id bp40GdpE82mgOwYAWB0awg (envelope-from ) for ; Thu, 30 Apr 2026 08:02:34 -0400 Received: by simark.ca (Postfix, from userid 112) id 582991E0BA; Thu, 30 Apr 2026 08:02:34 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 4F5801E067 for ; Thu, 30 Apr 2026 08:02:28 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id BD86843B5514 for ; Thu, 30 Apr 2026 12:02:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BD86843B5514 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by sourceware.org (Postfix) with ESMTPS id 88E994BA23F9 for ; Thu, 30 Apr 2026 12:01:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 88E994BA23F9 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 88E994BA23F9 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.43 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777550518; cv=none; b=vNNufxyOo5N8i55ity78v7juWA7lBWTxwJQye5Q6zegkjP5Lker9Xouor1sPhGIJm9dEmdhuSoF0gWAfRcgXYXK9yRlFSHJGQeLHovV1TLy70LT0mPVjOlrQrr0b2shMiMSaS7UKD9GwovN0UE1lNwVY6tz1UjbXB9kr1drwCCQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777550518; c=relaxed/simple; bh=Irt+IiFRjptl/tgS66gMSbiBb8A89V2zRNYgbp8Z7Ac=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=IWtfkmIjgL7CIWF/Nj+9Nix0bWuBkMAPlorbj/JsgLLpCvi0d3T+N0RXiCLg+p5LvahtAeZVLYvmqnHyHKp5Qjj/ZAus+gaaN40mbXtGW/jYKUjPqZLCZCkjmw83qYuDBiR0vl/mxrov42fm1c4miZtpccGlATX+20JVb75rTlM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 88E994BA23F9 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-488b150559bso5930405e9.1 for ; Thu, 30 Apr 2026 05:01:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777550517; x=1778155317; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1Tu2o+pFO8odiRE57+o2Z160QJGEZ53YNwA5JYf2/0g=; b=qXnU+2sU3DpBN8GS1upvw6yd6EVxcsiXBKqwfN3fgaRmd9bmgAqcOUQOo8msAGYuyW SCBXUwcSqnpehkDS++DXZKIVcoNI4iKUFURcUNhxxGxTTzWlOuuSl4CngYPm2lJX2md5 /DT3vzkZu0BqHjRrn9MXNFZ30ame5UzO2dpe9h7GbAd/edlp0lm4G5T2xJ5kyT2+3yuI qJZuoEu8BBNeu0hClMSa6N7f3giL6bhRpMBxj4oQ7q9fOdJ8ao7u/WHTlbsNfqrxps5n PBGZ6Gi1dBk2G3Q/MnpXLtIyeb5uwo6GphruI2maedeogJKPzvHhu8P5eAfWvIOxbGLd N2yw== X-Forwarded-Encrypted: i=1; AFNElJ9lDa74HgsexHp2IWb1HpXgQOjGGxxENGv29ZiAfiYTp6MxtSevRK5XEAQy4KkwDqf+7WRNBOnsjDgSTQ==@sourceware.org X-Gm-Message-State: AOJu0YyvSleZS5C/qpwEa4k0xgIuNy+cvrWVj6S91UtjkUGFRJuvaZkn a+GapY6Q1geUxn/2w+hR5zf5AgpzbWJBIRiErYZtZTyKHiXSPZyms5GL X-Gm-Gg: AeBDiev4D/gQZJUvyfcxSWG5F9fYSXQY97fXebtGL4/IfEjC2DYPnu1GhjN7IOuDJQf rkMmbqFKfOJiJtAXrAMIGDJtBXkAL/gg6eDnj6Hmr33uzptsxKFmcU0MQa+pVB7opX0gI4hSdWG IZgZs9kxMYFKCMcbx1nUn1KaarCiuzAzltEzjmRGwC3lu3WOme20ztDkNg+Hq0twiSb5tBFEReO YaWxtoPutV/SAS4CxSbqxCjz72zFJrb31g6uWkS0pVskEHdQPGFEMxemRALC+YXbMFCc0JxKB8N vWN0Fn1OMYkrxqyHuCDw7Jrl1ZODckViB4xr95NmcN47gP6tXchSj95M4zG5aSn6aZSIxejp4Bo +ggY/X77uvjjRe9hijDxPjhq+7DFddc/E6XJ+lC18PmG727uo0NypT2slnwQ7G2HWSQ8DJ9QGm+ 7hulaYaBAQq3UUtoS6e7XH89SkVspPkeRNtdcLsA/JVPkJ+rGGc8CVID9ksouWQVuNdpiBdEC9X Yzc X-Received: by 2002:a05:600c:4e4f:b0:486:ff92:63e5 with SMTP id 5b1f17b1804b1-48a83f6c7f6mr44043425e9.6.1777550516886; Thu, 30 Apr 2026 05:01:56 -0700 (PDT) Received: from ?IPV6:2001:8a0:facb:a800:7184:b702:c4f3:bfd3? ([2001:8a0:facb:a800:7184:b702:c4f3:bfd3]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a822d4b3csm60753185e9.13.2026.04.30.05.01.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2026 05:01:55 -0700 (PDT) Message-ID: Date: Thu, 30 Apr 2026 13:01:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 00/11] Windows non-stop mode To: Eli Zaretskii Cc: ssbssa@yahoo.de, gdb-patches@sourceware.org References: <20260429201507.480870-1-pedro@palves.net> <86a4ul3sbb.fsf@gnu.org> <601b9ddc-382c-42ce-82c0-c01d3266021a@palves.net> <86wlxo3dkf.fsf@gnu.org> From: Pedro Alves Content-Language: en-US In-Reply-To: <86wlxo3dkf.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 2026-04-30 12:14, Eli Zaretskii wrote: >> Date: Thu, 30 Apr 2026 11:13:55 +0100 >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> >> Hi Eli, >> >> On 2026-04-30 06:55, Eli Zaretskii wrote: >>>> From: Pedro Alves >>>> After the series, the Windows target backend defaults to working in >>>> non-stop mode (as in, "maint set target-non-stop"), even if >>>> user-visible mode is all-stop ("set non-stop off"). This is the same >>>> as the Linux backend. >>> >>> I'm not sure this is necessarily a good idea. Windows is weird in >>> this aspect, as you know very well: the system frequently starts >>> additional threads for its own purposes, such as handling the Ctrl-C >>> and Ctrl-BREAK signals. Also, many Windows programs have a separate >>> UI thread which receives and dispatches the Windows GUI messages. >>> Letting those threads run by default when the program stops at a >>> breakpoint is not necessarily the best alternative, and perhaps is >>> best left to the GDB user in each case (they can do that in >>> program-specific .gdbinit, if they need). Or am I missing something? >> >> What I meant by the above, is that the windows target backend code defaults to >> working in non-stop mode, but the user does not see any difference. When a >> breakpoint is hit, GDB still stops all threads. For the user, it still works the >> same, "set non-stop off" is still the default and I don't plan to change that. >> The "maint set target-non-stop" setting is just for how the backend communicates >> with infrun. I call this "all-stop on top of non-stop". Short for >> "(user-visible) all-stop on top of (backend working in) non-stop (mode)". >> This is how the Linux backend works too. >> >> When the backend works in non-stop mode (the "maint set target-non-stop" setting), >> infrun takes responsibility for explicitly stopping all threads when necessary, >> instead of the backend implicitly stopping all threads for every reported >> internal debug event. It gives more flexibility to infrun, and is a requirement >> for enabling supporting AMD GPU debugging on Windows. The user doesn't see >> anything different. > > Thanks. Now I'm even more confused than before, because not only do > your explanations contradict the literal meaning of what you say, they > seem to also contradict what's in the manual. > > You said: > >> After the series, the Windows target backend defaults to working in >> non-stop mode (as in, "maint set target-non-stop"), even if >> user-visible mode is all-stop ("set non-stop off"). This is the same >> as the Linux backend. > > The "Non-Stop Mode" node in the manual says: > > In non-stop mode, when a thread stops to report a debugging event, > _only_ that thread is stopped; GDB does not stop other threads as well, > in contrast to the all-stop mode behavior. This is a user setting, and it is talking about user-visible stops. GDB internally handles stops that the user does not see. E.g., with "break foo if cond", the breakpoint hit, gdb evals cond, and if it is false, gdb re-resumes the program, without the user seeing. > > and > > 'maint set target-non-stop' > 'maint show target-non-stop' > > This controls whether GDB targets always operate in non-stop mode > even if 'set non-stop' is 'off' (*note Non-Stop Mode::). The > default is 'auto', meaning non-stop mode is enabled if supported by > the target. > > So at the very least, there's a very confusing overloading of the > meaning of "works/operates in non-stop mode", perhaps even double > overloading. It seems that you are now saying that the maint setting > is just an implementation detail, specifying whether infrun or the > "backend" (whatever that means) The target backend, is the target_ops implementation. gdb/windows-nat.c, gdb/linux-nat.c, etc. I thought it would be a familiar term to maintainers. > stops threads as appropriate for the > all-stop vs non-stop mode. It also sounds like the "targets" part in > "GDB targets always operate in non-stop mode" is very important, as it > seems that it's specifically meant to tell something important. > Likewise for the "Windows target backend" in what you wrote above. To > a naïve reader such as myself, these all describe the behavior when > the program hits a breakpoint, because, for me, "target backend" is > basically a synonym for "inferior" or "debuggee". But you (and it > seems the manual as well) use it to specify two very different aspects > of behavior. See above. The target backend, and inferior are definitely different things. > > I think we should clarify the text in the manual, and in particular we > should not use "operate in non-stop mode" for describing both the > user-level "set non-stop on" and the maint command. I would also > welcome some wording in the description of the maint command to > clearly indicate that this setting is of no interest to users > whatsoever, only to GDB developers who work on this mode. Explaining > "backend" (not currently described anywhere in the manual AFAICT) > would also be welcome, as it seems to be relevant for this particular > issue, and could be used in the manual to clarify this. OK, I can take a look at this. > My current, somewhat confused, understanding of the effects of this > changeset on the Windows native debugging is that users will now be > able to specify "set non-stop on" without explicit need to say "maint > set target-non-stop on" before it, because the latter will now be the > default. However, the default user-level run mode will still be > all-stop mode. Is that correct? > Even with all patches applied except '[PATH v3 10/11] Windows gdb: Always non-stop (default to "maint set target-non-stop on")' you will still be able to use "set non-stop on". #A - "set non-stop on": To support "set non-stop on", the target_ops backend implementation (in this case gdb/windows-nat.c), must also support working in non-stop mode. This means, being able to report stop events to infrun without stopping every thread implicitly. When you do "set non-stop on", gdb checks if the target backend supports it, with a target_supports_non_stop() call. You get that with this series, even if patch 10/11 is not merged. #B - "set non-stop off" (aka all-stop, the default) #1 - If the target backend does NOT advertise that it wants to ALWAYS work in non-stop mode, then with "set non-stop off" (the default), then when the inferior hits a breakpoint, finishes a step, etc., the backend stops all threads, and reports the stop to infrun. If infrun decides the stop is not supposed to be seen by the user, infrun re-resumes all threads again. All threads stop and are re-resumed for every debug event even if it's an internal event that does not cause a user-visible stop. This is hidden from the user, though. #2 - If the target backend DOES advertise that it wants to ALWAYS work in non-stop mode, then with "set non-stop off" (the default), when the inferior hits a breakpoint, finishes a step, etc., the backend does NOT stop all other threads, it reports the stop to infrun just for that thread that got the event. infrun then does its business, and if it realizes the stop should be reported to the user, infrun explicitly stops all threads before presenting the stop to the user. This is more efficient in some scenarios. (For AMD GPU debugging, it's a requirement. And for remote debugging, it also enables gdb talking to the remote side while the remote inferior is running. Etc.) Patch 10/11 makes the windows target (gdb/windows-nat.c) work like #2 above (for "set non-stop off"). This is what that sentence in the cover letter means. Thanks, Pedro Alves