From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YhCYN80582k1FwYAWB0awg (envelope-from ) for ; Thu, 30 Apr 2026 07:15:25 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=qcJAo69e; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BC83C1E067; Thu, 30 Apr 2026 07:15:25 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,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 B52C51E067 for ; Thu, 30 Apr 2026 07:15:24 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 2A01B4BB1C2C for ; Thu, 30 Apr 2026 11:15:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2A01B4BB1C2C Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=qcJAo69e Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 356934BA7982 for ; Thu, 30 Apr 2026 11:14:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 356934BA7982 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 356934BA7982 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777547699; cv=none; b=qWh4BCBClIGBSx5cCxDHGzRTw8YEbCdT92drGHOs6YBzm4S+woxkzOt88XA99LAiD0ysCstW4SKOr79Zad3NbubUlfmZ4+ChLtYWTNeSDInNoC7KpT/tRD1Hlwmjfottc67I4U+SO4CFL/ZZ1r8unhbtzZf35BM+m47Gp9gT/Bg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777547699; c=relaxed/simple; bh=/e2WkIcai3QzBn4WVIt6kWD0NU9MAdgLck2ALeUyeSU=; h=DKIM-Signature:Date:Message-Id:From:To:Subject:MIME-version; b=FIQYSiwONLMzUJNK1X5VT76VwBBs47N9myK/ktFqdkJuapmjTqE5wDgdRXM/RFWnJ9+u4isDHNKArliLaOjweBkkal3MsXiXZV6blUndJ4znV6c3HXl7FI6nH/jUPH2NQZK0YnI0GF6Z7nWOZjmtozr5eo4drbuBeR5+ZUHbncc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 356934BA7982 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wIPM9-0005Om-MH; Thu, 30 Apr 2026 07:14:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=LEJhm05g2EDhp7a/U0NsL4IneQbn+ohYp4NuzNl9wyo=; b=qcJAo69eBTdzU0bmeZeW VrrrfAOXLWwOVOA4CxRKin4y5xfvrlK3S7Tj0bKBnkYMMf5soolWCDTnW0qY9IRco5wmM/tDbtV7j ibRqOBvMe0MyjXQHbzjph77A6trKYTRv7Yz96v0Y+WHcq2V0T/Lvn2ogLTrTa5H0SNreb6Df0zvKz zg1UCPv/uGaFOjFqeHYLdfbnG2Sm4EsV5LVUBWpnCOQrMZ9ESCnmS1mtXbV62JVICtEGAdD0CaoI2 T3eHmWZBpFh4LmN2rkUzSySl2zGQdptOEVoJJ+5llJ1+PcXuNZJ+zRtMNINaTVr3bCCWTdQZI5mhg fX10L0P/g9Ww9Q==; Date: Thu, 30 Apr 2026 14:14:24 +0300 Message-Id: <86wlxo3dkf.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: ssbssa@yahoo.de, gdb-patches@sourceware.org In-Reply-To: <601b9ddc-382c-42ce-82c0-c01d3266021a@palves.net> (message from Pedro Alves on Thu, 30 Apr 2026 11:13:55 +0100) Subject: Re: [PATCH v3 00/11] Windows non-stop mode References: <20260429201507.480870-1-pedro@palves.net> <86a4ul3sbb.fsf@gnu.org> <601b9ddc-382c-42ce-82c0-c01d3266021a@palves.net> MIME-version: 1.0 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 > 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. 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) 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. 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. 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?