From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BaByF4cSY2ju2iYAWB0awg (envelope-from ) for ; Mon, 30 Jun 2025 18:41:11 -0400 Received: by simark.ca (Postfix, from userid 112) id 4FC511E11E; Mon, 30 Jun 2025 18:41:11 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 006FE1E0C2 for ; Mon, 30 Jun 2025 18:41:07 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 60AB2385802C for ; Mon, 30 Jun 2025 22:41:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 60AB2385802C Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by sourceware.org (Postfix) with ESMTPS id DCB8D385B507 for ; Mon, 30 Jun 2025 22:40:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DCB8D385B507 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 DCB8D385B507 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.51 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1751323229; cv=none; b=x1WUKlCgf3Mfj/m1Hg3UBJ6nT11XtzmRv6/WXdY+DrMw//xSVqSYFFMllQWOjx9Ak69ItQu/FiBLmdHEYXgmcmqCwMKgqR0NO+gEgX72pzHjtFQFUSfSEMeIFX0P+0MlplaUDeUPE9D3nOTW5iZNpq8aAtHHLyuF4YXa12ZBq8I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1751323229; c=relaxed/simple; bh=LeAU7vafId7bjSZ51At6dMoAXFcwq1/yqxN8AsQHUFE=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=RBStxgydzXjrvWzXjwbtKaUxfhlREzNR82oNroxmXCrs0B5i+M37F+JBfcsej9QclFTjD5uLVqPV14Wtl9NYcUHxmTzPDz2/s8NuzWHz/Fxq+bZrQfQI+EKZrQ3L5c85l8KxMtdFyzbJHbsRQxhF/Bk591AeB8pbnDRVFpuzlsM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DCB8D385B507 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4531e146a24so29864035e9.0 for ; Mon, 30 Jun 2025 15:40:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751323228; x=1751928028; h=content-transfer-encoding:in-reply-to:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7V1vDy1ph6rwHbO35jkiICY0qLPu50QSKz2d/XLrDJg=; b=EuaFNhCIfwvtN6R4nT+TMfBAUY7n2jG9E71F2F4F0UnHYDSkZKejwr5d0fxh13PAUh t77k4W1QISG5Dge9USNJjiHUFmjljfIFYFqUh1kDQBj/+pXTwnwj143NqSirv1onmfnG SV2cnAeT/4tTHl6e5wQCIutyr32dGBODh56f9US+nSnFhKS3WUSJwmRuAfZ3xTEFMtK9 7eQD4DOLWjaktF9yMOw7oLPg9OqCv5Zbv6ye72fHuDdR6b15blySugyaW/6itp0cC4cz PP/s4+9mQys3XOYUpXSS7vJv5zb0t4R+GhHYY/+YP/KEop69pHqJ2dQw3XTtW+Wr6LKE xlWg== X-Forwarded-Encrypted: i=1; AJvYcCUGo1zd2gahKyORrAgY+XFuC6UsyD/nNEsCQt3uBuPr7Qiz6KYW4WwljiPawhdL1bBQeSX1kFeZvSIfHQ==@sourceware.org X-Gm-Message-State: AOJu0YxlC6xrSeSZ3mummvjVg4OtkzjeCazn3f0S+zbGrKSKXbfeV5DQ qoVFUNtpyoEWVoxyPRCWnDaO1G7VD/kUH+PMzzBRSzizagaL2SfP2FGs X-Gm-Gg: ASbGncu2OQWzxATyH4JrlT/TSLiVSb/DN9hAfHTdUvYT6ZpTLmZjfkSnp0hFi9T1rNL krvPv+oI2h5MDCAlcccy9UJW0MBbz5PdAJ2wEdeO1GoZnyx+ZjVaspS60UgjfMj3z4SibW8KH6G /+jw3WWo9x5nlpp9X3EmFbmv5yZSSw0lynqTQjEKvJZePgtRJkNm1iSAzmpPwKynBk54yaVyUc6 6csAGqFdUtzGAcHncaKYRfTe6sS9VO3j6Al/bdO2zp1G0Ka0x81b4nAb5q+obHASkxHld59TzrE i2PF2oRCiSaULm1aY3CyMOsKeVx9NJlBazGDQaGQNj2m1L2KHdlRr6y95CaXpIG37DSv+bZL5Yx I46L7nxpk4eBERWISjYwcxGJAS2DBmw== X-Google-Smtp-Source: AGHT+IHKTz+wcFXX10IYqjmY5fjTRydaiyrvvS1fAp/kFbndm5VlwuQfpYhITfplqlL6N041PM93rQ== X-Received: by 2002:a05:600c:4f95:b0:453:23fe:ca86 with SMTP id 5b1f17b1804b1-4538ee50438mr157321015e9.4.1751323227260; Mon, 30 Jun 2025 15:40:27 -0700 (PDT) Received: from ?IPV6:2001:8a0:4284:9b01:fb34:f54e:9a51:ed03? ([2001:8a0:4284:9b01:fb34:f54e:9a51:ed03]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-453b35349f0sm1458255e9.1.2025.06.30.15.40.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Jun 2025 15:40:26 -0700 (PDT) Message-ID: <88dde382-0a4d-4c6e-a320-d2df1a163ccd@palves.net> Date: Mon, 30 Jun 2025 23:40:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Improve attach on Windows To: Hannes Domani , "gdb-patches@sourceware.org" References: <1549974991.1116105.1750000125453.ref@mail.yahoo.com> <1549974991.1116105.1750000125453@mail.yahoo.com> <81ba0310-7b26-43e5-8770-1c2dba9f73f3@palves.net> <1300261172.1158331.1751218712472@mail.yahoo.com> From: Pedro Alves Content-Language: en-US In-Reply-To: <1300261172.1158331.1751218712472@mail.yahoo.com> 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 Hi! On 2025-06-29 18:38, Hannes Domani wrote: > Am Mittwoch, 25. Juni 2025 um 15:32:00 MESZ hat Pedro Alves Folgendes geschrieben: > >> Hi Hannes, >> >> [Guess the list was dropped by mistake, adding it back.] >> >> On 2025-06-15 16:08, Hannes Domani wrote: >>>> Automatically switching to main thread is IMHO more useful.  That >>>> results in very similar output than what we see on Linux: >>>> >>>> attach 5164 >>>> Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164 >>>> [New Thread 5164.0x87c] >>>> [New Thread 5164.0x28f0] >>>> [New Thread 5164.0x376c] >>>> [New Thread 5164.0x2db4] >>>> [New Thread 5164.0xce4] >>>> main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19 >>>> 19        while (! should_exit) >>>> (gdb) >>> >>> I wonder if we should do something similar when Ctrl-C is hit. >>> >> >> That could be done, I guess.  I can think of one downside, but I'm not sure >> it's strong enough.  If you're debugging a program that has a Ctrl-C handler installed, >> and you decide to pass the exception to the program, after GDB intercepted it, you can do >> it immediately with "signal SIGINT", or "queue-signal SIGINT; c".  But if GDB automatically >> changes threads, then you have to remember to switch to the thread that got the exception, >> before issuing the "signal" command.  Maybe that could be sorted out with a warning.  But >> then it might be annoying to see the warning all the time. > > Why would you have to switch threads before "signal", when the signal > is anyways handled in a new thread? "signal SIG" makes GDB pass "SIG" to the current thread. On Windows, you can only pass a signal to a thread if that thread last stopped for that signal. IOW, on Windows, you can only decide to pass the signal the thread last received, or to suppress it. See windows_nat_target::prepare_resume in the non-stop series, or windows_nat_target::resume in current master, where it reads if (sig != GDB_SIGNAL_0) { if (windows_process.current_event.dwDebugEventCode != EXCEPTION_DEBUG_EVENT) { DEBUG_EXCEPT ("Cannot continue with signal %d here.", sig); } else if (sig == windows_process.last_sig) continue_status = DBG_EXCEPTION_NOT_HANDLED; else So, "signal SIGINT" on a thread that was _not_ the thread that got the CtrlC exception does NOT pass the signal to any thread at all. If the thread that _did_ get the signal is not the selected thread when you issue "signal SIGINT", or, if you didn't use "queue-signal SIGINT" on the thread that got the original CtrlC, then that thread is continued as normal, which means its SIGINT is suppressed. > > >> BTW, in the users/palves/windows-non-stop-v2-plus branch, you'll find some extra patches, and this one: >> >> commit 95bafb7217bac2d51f5b6a59d34d79bcbaa1eddc >> Author:    Pedro Alves >> AuthorDate: Fri May 5 15:51:31 2023 +0100 >> Commit:    Pedro Alves >> CommitDate: Mon Jun 9 18:49:19 2025 +0100 >> >>      Windows all-stop, interrupt with "stopped" instead of SIGTRAP >> >> ... is sort of related.  It doesn't affect pressing Ctrl-C, but it affects explicit >> "interrupt", like: >> >> (gdb) c& >> Continuing. >> (gdb) [New Thread 11688.0x2ff8] >> [Thread 11688.0x2e30 exited with code 0] >> [New Thread 11688.0x3040] >> interrupt >> >> (gdb) >> Thread 1 "sleep" stopped. >> [Switching to Thread 11688.0x2e94] >> 0x00007ffd839118d7 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll >> >> >> For Ctrl-C, it might be possible to make GDB see the Ctrl-C before the inferior does, and then stop >> the inferior with "stopped" too (i.e., just suspend threads, no exception injected.).  I still have >> the Ctrl-C rework series that makes Linux work that way (by making the inferior transparently run on >> a separate pseudo tty) that I hope I'll eventually be able to get back to.  Not sure Windows would need >> a similar treatment, though, but it might. > > I'm using your Ctrl-C rework series on Linux for years now, Wow, I never thought anybody would be using that patchset locally, especially as its such an invasive change design wise. Did you ever run into any problems with it? > and am always wondering why it wasn't merged yet. Simply lack of time -- I keep getting pulled into higher priority tasks. The last time I posted it there were a few details raised that I need to address. And then time flies and before you know it a few years have passed. > > As for a similar treatment on Windows, I guess this would be possible since > Win10, but only needed if "new-console off" (I always use "new-console on"). > Right, like on Linux if "set inferior-tty foo" is used GDB doesn't need to do do the pseudo tty dance. I don't recall off hand if on Windows there's a way for the program to suppress CtrlC exceptions completely such that it isn't possible to interrupt the process in GDB with Ctrl-C, similar to the way a program can block SIGINT or use sigwait on Linux, which makes it impossible to interrupt with Ctrl-C. If on Windows, pressing Ctrl-C _always_ makes the kernel inject a new thread for the Ctrl-C exception, then I guess the whole intermediary tty thing (which I guess would be a hidden console on Windows) wouldn't be absolutely needed. Though it may still be nice for other reasons, like having total control of the screen with the TUI. Pedro Alves