From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id f+0iL9QOZGj+9ScAWB0awg (envelope-from ) for ; Tue, 01 Jul 2025 12:37:40 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=yahoo.de header.i=@yahoo.de header.a=rsa-sha256 header.s=s2048 header.b=Gqq5YLcV; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B07801E11E; Tue, 1 Jul 2025 12:37:40 -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.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 B60421E0C2 for ; Tue, 1 Jul 2025 12:37:38 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3F211385DC1A for ; Tue, 1 Jul 2025 16:37:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3F211385DC1A Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=yahoo.de header.i=@yahoo.de header.a=rsa-sha256 header.s=s2048 header.b=Gqq5YLcV Received: from sonic311-31.consmr.mail.ir2.yahoo.com (sonic311-31.consmr.mail.ir2.yahoo.com [77.238.176.163]) by sourceware.org (Postfix) with ESMTPS id 2644B385C6FE for ; Tue, 1 Jul 2025 16:36:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2644B385C6FE Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=yahoo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yahoo.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2644B385C6FE Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=77.238.176.163 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1751387816; cv=none; b=rzSkALkLE19XuiR/Rk8NKy9HSikpkAflnlHBUqdZRgVxnqkVhwUOI8xb+0441IbIYZqyKDIC1Ae63q2nPlPRv6VF9rZor42TVCY5ACDLzIEa6TRcwymvk3Ri0HbcwlwzGYXfZVFgBSCtXpeuR5fMT0UfgyCQPA4fB+alVG99/BI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1751387816; c=relaxed/simple; bh=hmoqCKxgjQkMcHiTfLB5vQuEvtol9sf+LCpcDrCm0/c=; h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version; b=pMPb57hAyLxnzmlN6QXiZK+DzaKDcy/rzLV4NJtrWv9XyuxvH9zAg4YUwQkvj3Qqet8wLpOtfVX4R0mMCS7gdFmFMR0Pqi4XdB23f9hqKmzaWjyjGjFK89A4e1MF69wbgAt5eiP5I2eWi1XLIhos+TcmvBZgmijnVcayPK9Gw5U= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2644B385C6FE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1751387815; bh=hmoqCKxgjQkMcHiTfLB5vQuEvtol9sf+LCpcDrCm0/c=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=Gqq5YLcV3sjonabbdd1Wu97Vin6ZzrIsmWx6eAyuFOleOeAMrSfrVWjtx8D0NQCfs7SnzxH60w+hhMg59yjUyFbwCjqUfspTrnOBCuy5uGCKa4cA7iLmUrxwVtclnrWyJcrpnQyjC+WS56wjjLtnEbzEJgLEQs8qMIZMg78kNCvjDUAjADYuE0pfziGFJUhon3rcfSd41sdBPeCgQw+Dq6fQQy2pww21HqEFns56U28cwKPu+aJ1s/8NEAj152+84opCmsqlm///weLgx+AEWhuHk8Hg5AqKRzpUPNNhrvqHOni8u5aK+ZVBQZJ0jMY4lqgyYiHLV14BkxvOjy14wg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1751387815; bh=brcaMz44MzD2LpXRmfDik6LR8yyirVZyGy1Itx5uZ32=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=RdgYs7/4SGXAnG8gHrmlCsf9BjgaTj7xZ8eE5ZgYnMR6ueeDa/v1zIuhtDsfUYlvQeEwklv9CoHV8Yw/gbNAdmJ/C+Vlnkvj6SDMQpE0Ps72KVHLrpTGFGhgjD/2/ClVzzlKjDhyghrGb2vbX2VZYtwykY68sXSPNxdtM5vgR4fcH3lD3qrbo8d8SshUM0eeV0O2k1GjyePIBdgexpV0xXZmhSPJelsaJ/1lzvAcSF0mrah+jVyYQ6BBiAuAMcCR9WdmHDIGq9OlaSO9+BvRvG736wzdEk+Dxq5/UQAC7OeWxa5baVMzAk0cNobI+W4dlMa0WHTcZuo/9R9O0ZfixA== X-YMail-OSG: GP.1u0EVM1lwWyk1v7cmCtzyfJMzNMt5EY6qo_89IAu.mQdtlyea2Q8y4k7GOyU n1m27uipp73ErkyHadSDflvwAZ.OhjMkn8dJqXrqvc_zM6AtC.z_xHqhuTYVwNCAhTNv32llsYKr eNFBxsZh5tmY4BIgcEHtpSAgRBUsblh50P48P8pxrNwXiFaJ6VbdOQSkWcFCeeSpWXQzc5ybJvYO y2KQZ5X.3KtH98X58EfkTHOXX7JXMs4RrIS161.1myZy36jV9fboTOQLDwGXopR6TY0K4RAZk_eG nJIXNeKQy5O06Ev0_RMam71j9LExE8tM5YIRg5OWBooEebQJgR7U9H8EyTYucQjEfVKY4cobrFIL rDUhwN0l6i64eCzVnqTOkkrlaH6WxJxRxrrTAgL.hCfAHN261W6LdJfxsparnw51w0Y9YAmfhLRk QEp0XNDc_9VOQ4OGxf2lZ3j9DpGe5s4bKebIMSy1T.ChpM_5IkFt.XQ42qJ0biEYq2eqRFj5jOCA OGLl5omC5nBu.37ao.p23.4xbSKl84naZnqQmDXtdLQ7UZv8dMH2CKnt8JKCst1QCu9BnZTp6DQw wyWTKdR3knLbDIncdlSYvG2NO8k13mix1g8Ey1un.0QsLvGCRBOMpYUo8Vyi2YvzWhaprIk2IBwv ivoMnF1uQA2OxqPNLJS3Pxo9J3N0ckoc3B1GyIC6AANsKuE4E1EVAzKC.c0QGGD6uza9I9mt8HFp L8iqpWtbLnYfMFITZUEFHOHR4.g4veRry6QyI8XIECMUlDeTRBXo9fHP6wypbFPogcf8kzTy_OX2 kHOW6jk.vcyFbVB0MeJDBm2mqFrChabcK91DrCDhVZwTYa.qoJjqtCvtTcL11Lu5_ydx18kfwGEh WvPms.V.xOEYgoOUiZ.XxcjYf244kOUAj9oZxRDRowh6yqYl8J8n76_sk6TNDqoUyUWPNt4ErpDz bP._vRpY3iNB9HLXJEqcM6Lhy_tMTkgPbr5caM0_ETZWgvnMiWeQsmMAszELNFH3QCUmdLe9vz05 2nY_KPoKQHacBOTDDKOwfeFxzzp_G_WLut0dADQwFDX_H_x8OxQLRoJw5Tv8n3QCbYL2kHRKco0N JIVKBkuqK5SM6DxSw7FmttGOsyQx9.rBrSLbH0_1CUe0.KjbkzY_dhHhcs2Q6PkTZiUpCy8j2dbi yAs_znEk2.FTZ.I1hx0KzjexiH_EPOjRUxIGqcEwqILhXEsVTcVIoQEtY3DCDxk1Fc1k5arStCn7 XRU9D1RDtjNwLx1mfkF_IihRx6L04TpToCPPj6dTi50jGDtMnx4cflNvW0hXx3Yi2tx6iZheoOqU tIege18KWvobB.vKJ2P0AzhzKktol3yItTHczGBhWHxmw0jpviZCGblMaCefZ7Px6S7E8oousHUR Maj1fv21SqgKo9M3Omk066u6OG57asGROFlNEWH48XBtYvWxLyWdI_r8ZMiYu8qxKgaZnXPFpU7A 84cwqElape8tfZ.P1KBXvpQJFwWW_L1DCWBokVPAQ2n0Uvag4MlFJgPkpi381f3P0E8Uo5DxAr8m 6k04xQT1By0DsFbBds9F9lm7TsHI4CtC0jJMZN..P8aTprqEOQhzyA3ysfudqXSscokSeAh34mdv j7cMYjeAJ.sPvHCot6UbGsyMaUDQVzQEFasCeWUnM7HauXCOdTnG1LJxivMGBh2mMhjcb_w7RRkn DMumIdjgmlTHG1alyQKHzrNX8_Du.UAjTgZIqknUDPN6AVTiRqwcThZ41yFxFxEBbsdjoRtUC.pz fka4ZB5qQ7RXEsywtA1xHfqOmHtKoouieXNivVheIPR3KujYZUlStITKYDkHWgIp9boCuODVeXB9 slZ8GQLL8V7DLAPHIygfJHHPjJM8JgdhXLUnb49V_vHykUAKiSDkiRnD3xsWnh8VfawshWHfaQbM F0gaUgZjNWzIWZennZmGuz4sbfVGaBo50AFiqSZxsHBNJJzAxeyXBWE_WhpYQukr8qHOfrgTuQB2 iwX8iI_cZjOb6ziOC8Jnt8Vmu2js2w.JweCbG_yadZXcwdcTuR6Qd3AlcWe7wO3ZCoSzqRjXfBGc O5ZnEyJsILRTSxnQ22t8Dn.Q1GIgq5yZRq5XMONyqZF6VWpKyP6gqlvaKE2OjM_W0hig3UncTIEK cegyZ7FFb7LT6mrX8n6NnffFpraJaYvd0NaY1lIv6mHSlWKRF_fifLvVUsxGWBtNgBRjrCmOZiIE 0mPWxTdUWEbkMrLikh_USgaVScI9hqnc9MWnyvGd1UO7qUms5C.tMN75OowrgakpO92_G X-Sonic-MF: X-Sonic-ID: cc58d8d0-e94b-4608-8be7-3c147f68743f Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ir2.yahoo.com with HTTP; Tue, 1 Jul 2025 16:36:55 +0000 Date: Tue, 1 Jul 2025 16:36:49 +0000 (UTC) From: Hannes Domani To: "gdb-patches@sourceware.org" , Pedro Alves Message-ID: <1518094155.2627551.1751387809635@mail.yahoo.com> In-Reply-To: <88dde382-0a4d-4c6e-a320-d2df1a163ccd@palves.net> 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> <88dde382-0a4d-4c6e-a320-d2df1a163ccd@palves.net> Subject: Re: [PATCH] Improve attach on Windows MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.24076 YMailNorrin 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 Am Dienstag, 1. Juli 2025 um 00:40:28 MESZ hat Pedro Alves Folgendes geschrieben: > Hi! > > On 2025-06-29 18:38, Hannes Domani wrote: > >=C2=A0 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.=C2=A0 Th= at > >>>> 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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 while (! should_exit) > >>>> (gdb) > >>> > >>> I wonder if we should do something similar when Ctrl-C is hit. > >>> > >> > >> That could be done, I guess.=C2=A0 I can think of one downside, but I'= m not sure > >> it's strong enough.=C2=A0 If you're debugging a program that has a Ctr= l-C handler installed, > >> and you decide to pass the exception to the program, after GDB interce= pted it, you can do > >> it immediately with "signal SIGINT", or "queue-signal SIGINT; c".=C2= =A0 But if GDB automatically > >> changes threads, then you have to remember to switch to the thread tha= t got the exception, > >> before issuing the "signal" command.=C2=A0 Maybe that could be sorted = out with a warning.=C2=A0 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.=C2=A0 On Windows= , you can only pass > a signal to a thread if that thread last stopped for that signal.=C2=A0 I= OW, on Windows, you > can only decide to pass the signal the thread last received, or to suppre= ss it. > > See windows_nat_target::prepare_resume in the non-stop series, or windows= _nat_target::resume > in current master, where it reads > >=C2=A0=C2=A0 if (sig !=3D GDB_SIGNAL_0) >=C2=A0=C2=A0=C2=A0=C2=A0 { >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (windows_process.current_event.dwD= ebugEventCode >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 !=3D EXCEPTION_DEBUG_EVENT) >=C2=A0=C2=A0=C2=A0=C2=A0 { >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DEBUG_EXCEPT ("Cannot continue with s= ignal %d here.", sig); >=C2=A0=C2=A0=C2=A0=C2=A0 } >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else if (sig =3D=3D windows_process.l= ast_sig) >=C2=A0=C2=A0=C2=A0=C2=A0 continue_status =3D DBG_EXCEPTION_NOT_HANDLED; >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else > > > So, "signal SIGINT" on a thread that was _not_ the thread that got the Ct= rlC exception > does NOT pass the signal to any thread at all.=C2=A0 If the thread that _= did_ get the signal > is not the selected thread when you issue "signal SIGINT", or, if you did= n'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. I didn't know about that limitation, goes to show that I never used the sig= nal command. > > > > > >> BTW, in the users/palves/windows-non-stop-v2-plus branch, you'll find = some extra patches, and this one: > >> > >> commit 95bafb7217bac2d51f5b6a59d34d79bcbaa1eddc > >> Author:=C2=A0=C2=A0=C2=A0 Pedro Alves > >> AuthorDate: Fri May 5 15:51:31 2023 +0100 > >> Commit:=C2=A0=C2=A0=C2=A0 Pedro Alves > >> CommitDate: Mon Jun 9 18:49:19 2025 +0100 > >> > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Windows all-stop, interrupt with "stoppe= d" instead of SIGTRAP > >> > >> ... is sort of related.=C2=A0 It doesn't affect pressing Ctrl-C, but i= t 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 except= ion injected.).=C2=A0 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.=C2=A0 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, especi= ally as its such an invasive change > design wise.=C2=A0 Did you ever run into any problems with it? Can't think of any issues at the moment. But the main reason I use it is because the pseudo tty made it possible for me to forward the inferior output to a dedicated TUI window [1]. (nothing fancy, no handling of terminal escape sequences) > > and am always wondering why it wasn't merged yet. > > Simply lack of time -- I keep getting pulled into higher priority tasks.= =C2=A0 The last time I posted it there were > a few details raised that I need to address.=C2=A0 And then time flies an= d before you know it a few years have passed. > > > > > As for a similar treatment on Windows, I guess this would be possible s= ince > > 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 t= o do > do the pseudo tty dance. > > I don't recall off hand if on Windows there's a way for the program to su= ppress > 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. See removing ENABLE_PROCESSED_INPUT flag with SetConsoleMode [2]. But as far as I know it's not possible to suppress Ctrl-Break. > If on Windows, pressing Ctrl-C _always_ makes the kernel inject a new thr= ead for > the Ctrl-C exception, then I guess the whole intermediary tty thing (whic= h I guess would be > a hidden console on Windows) wouldn't be absolutely needed.=C2=A0 Though = it may still be nice for other > reasons, like having total control of the screen with the TUI. Yes, that would theoretically make a similar TUI window possible. [1] https://github.com/ssbssa/gdb/commit/7407d0214109314e2bb559949a2e8f33e9= c001d2 [2] https://learn.microsoft.com/en-us/windows/console/setconsolemode Hannes