From patchwork Mon Nov 28 19:15:26 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hannes Domani X-Patchwork-Id: 61192 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0C140385B513 for ; Mon, 28 Nov 2022 19:14:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0C140385B513 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1669662847; bh=tbehr68yeoGGR0aYMm7Yg4ehFyP3n0bg+6HdrSGbG+w=; h=To:Subject:Date:References:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=ZV5tVoJXUeiCfyqxKutdT4gV5wJNf8JH1pK1r9DmjWJS3YCDBAJ+f25VfDlFiM5ZT w3x9G53PxkftlZiF5hwo+qHTeVwMSlaRXmyIhuUew+Vdar6LDTOKfnqdArMzj5HNGu ia3iZICq4so0iyV4XplaE8XC2oZPAfnzfeddIKlk= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from sonic304-23.consmr.mail.ir2.yahoo.com (sonic304-23.consmr.mail.ir2.yahoo.com [77.238.179.148]) by sourceware.org (Postfix) with ESMTPS id 4852C3858C62 for ; Mon, 28 Nov 2022 19:13:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4852C3858C62 X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669662821; bh=ph1Hgu9Of9H7nSPkMmA8nrbFqwN72o4oQZ2O25slr2R=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=t7BRG3DbgTyN6N3wlH4JBPIB+R4qPmLj/Cvma6YIvKRXkX9R08XsRUuNv/sW6SwmDCy9FKtLwecffVCXpVHRO1a8byy3ptkv++h8wh9o/NxbWW9+vk6L/lSh8Wx1aqzE7QC+KOjHbTNHo0k5EIqVVTY9vLCzk8sggtc3i6b26dqRpq0WZ/tpyT/1VOhEXEXqf94o6ehS/PzcDtrJg8E4iQb2Q+BpGBaOO5g4OJ/vg9v22/lapNsinNE21d2Nbr73QTOv/KFt2S10C5blRVFeHpDN11Zmvh89AuX3mb/IX/RVA+56M/c8f9bX9P3O+vzGGvWzU9iNoTSsqD85Pp006g== X-YMail-OSG: _nD0DEAVM1lLfD.VB0vGicM8q4I9F90MWorAzKZVy91s1tkTUs4NTlETpvThFJ1 he5nTe89eFc2lDBJK35xDLRFqlC4OEnOMdcZq9jt76hrBFeuFTLxax0MvfM8VMAev0y4x4XwQw12 ..a8JkiVv0yTpq4865Gj8r4DYAvlGKUYEu3kTaGQT_PvyT5ThXOx9goh8QA275T0jKf0Ic6BqmA6 2FKgTx8tEBCPLcNPPuGE1toxcbWxyW.dXB8gJhhwe3hYmjEH1IgDPG1tE2kM1fcB_1LgpiqX81t7 GzvyhEjprw.pa31oun57d3MF3VuOa9cZfThkZUMBpOpnnShNbnTuaDDpieCOsS1YZTc5YUuWRzaz gV81TAwCmFeuFmNyzZLX5re8KticfphmOk6hPmHbArs7NFnIKmYZmX4HEkC1vAPAVUwopqG45EwI 98L3mjL0XuxRtpmLeNn9NFCGkzxBBm83A5a4.MiEuTk8LM9I0fgO0bdKM2ke3FTa42Uo_w_A4AXd ZkPC2J.g.LcFAr90useADJizk7tgJstzJbj7.6yRdrCQ35Yw.iflqBVKmtBC4lpfa1C6zYTi1axH qSHTlr_iYeMtDgl5CkdluwAKhxn3hZlmoKsmS3uFpu4IbT4dM_SknEdSJwxzkTP75ewU1O12fb_8 qLDBIdosSZulOeKJKH1CZVK11VLpqFdLW.N2K8OeaZ5uqgrqcd4PMiM_6CFOHw4fRvl6fkTEY9Wh 8qQInaotqZBXf.YVtb6CV_mnJvy4nl6nsq8L0bJzc8RAXSWxvSjkbYdOILoRvPzxRoUrBtaC4IXy 1O0KsA1uKiop0SByBht5Q4NGRAbygS6JgEDzKKWb5v5KQaRwGHmnV.v8XGitUvNZ0WCXRWGXM5NQ k7zCDE8DAL6lr011x_8nwozSAY_shgLcizpvolntpqbBOPK2XYzUXEoGK4AVEb33NxDyg5fd9a6h hmLJ0HrAaLcG2JoRCjVJkfv59tW9.IoflgcXK6hcTomNoNioCc4d1qCzw_jiI_edvOU3ZR2oSHiw _MjTaNyZYjLuerSPdTRJWB8dntQ7Lai_OzY30GntzD8kSi6DGq_PorIjelJ7LBdSB2qL5lLbjYMH _gpqEwe6rqxThGseHaDa1xXyDNX4Q3VnTqN719HjwPY6Dj3Dz8U9.HHR2Jg0poixOEiy8VbyB_Ka hj1ZikYikvy4mdjmP7saTNfY_DXNQaPiIIuJks7baL77ygTmQ6ZfjUIbn9WNWDVJ9AxIBKUgBv5j 4oJvFWpNk7Vl1oq7WcjUs35zfaGScQ8pB33fg7PKj.U1PI7zEdt3iPYdLHyQmM02S.00rs_tE5RD _0LYhAG_N8yt5dwG0cEz0BuMoF5wkcXFgx5KOsGMXiOB50cegEKlLOR7luCB3HA7REm5YJDi1TId fYfOer_hT77C2YPGkOQCzJ61wUGPAXMO4qicBaXc4541mvtx.uFEOBn.AyKoIqltxnOgJf8v3WQK La_Hv40pzLzYUvNAwALEHe3tmw9mGDcDQXngKvBM_5E_uhbqzQO0cKhbn9mjz_iwE0QkgaG5WuZy HjwWPpEw9PTSy4pAlAqfpuSOZlHgtUvMTBuhkGNcu2Sqn8jPkREcmGszJiZkFM_4sZDhVIIgnTZ4 siKszT32T7JyYW6b8KWDqouMa77TPJgRgR2w8MtPwW23Sk_1GIK4HnvHEMiEogtdmJB8B1ZsZuHx _x9mUsk0kFuKCKE_rjwP.PjFyoBZCGFSM3PcSKnOAS6i1FPrrwS1L75a8GvchxzKUNZrxgTGXeXP VZIJ4yTnCWIKBtQHlH0N0SYIDoFkBI8Yif95XFlLO0F1nT9UPprXFsayDCuBo9l5TW9216rRbvd0 Vx.UKgJZ6KqHvp3fhYqM_BeT3TuwkMuySlX67wV1PtP4MefVpuSI9st301XOXa7uQwRZ16rFkDHL qGNQhiKoSQVC.4Yq7MAkEpm6Nv0iIkjtgUkPhNXQ0837jhxz32hGR7B6J6kCPeZWboKSiEKOJeeg gYKBseD3CSk3DYF_MHnfHtrjKruzZnAvmTX4OLNWDcsv2NDHSdY2JBL73DGMQYwvGQ85cShbPSuS N.WvvULt4e3dwAaB4B9slAybll_FxX3Ou24GUaXT5EY9CjPiDZRm.pYmje3l0Ka0bsbIOcURGA4v J75Hehlw3VQG8IPZ21FSi60My5hSrwvqa0MfKdYWyN3ADCyM8mQnfMJHG83.sc54mccxZNi7KW6l UvTGj9hcloEVoAPxLt3h9_buupEmCXZuLtyg- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ir2.yahoo.com with HTTP; Mon, 28 Nov 2022 19:13:41 +0000 Received: by hermes--production-ir2-74cf6dc4df-jcjh7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 95a0e1486cdc393c4437e9ee729bffc3; Mon, 28 Nov 2022 19:13:40 +0000 (UTC) To: gdb-patches@sourceware.org Subject: [PATCH] [RFC] Move SetConsoleCtrlHandler calls to async thread Date: Mon, 28 Nov 2022 20:15:26 +0100 Message-Id: <20221128191526.1426-1-ssbssa@yahoo.de> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 X-Antivirus: Avast (VPS 221128-0, 11/28/2022), Outbound message X-Antivirus-Status: Clean References: <20221128191526.1426-1-ssbssa.ref@yahoo.de> X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Hannes Domani via Gdb-patches From: Hannes Domani Reply-To: Hannes Domani Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" Ctrl-C and Ctrl-Break don't work any more since the async commit, so I've tried to move the SetConsoleCtrlHandler calls. Now Ctrl-C seems to work, but Ctrl-Break completely stop both gdb and the inferior (if new-console is disabled). I'm not sure what's the proper fix is here, please advise. --- gdb/windows-nat.c | 66 ++++++++++++++++++++++++++--------------------- 1 file changed, 37 insertions(+), 29 deletions(-) diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c index 17422e15f80..e1034e48da3 100644 --- a/gdb/windows-nat.c +++ b/gdb/windows-nat.c @@ -209,6 +209,8 @@ static CORE_ADDR cygwin_get_dr (int i); static unsigned long cygwin_get_dr6 (void); static unsigned long cygwin_get_dr7 (void); +static BOOL WINAPI ctrl_c_handler (DWORD event_type); + /* User options. */ static bool new_console = false; #ifdef __CYGWIN__ @@ -477,7 +479,37 @@ windows_nat_target::process_thread () { if (!m_debug_event_pending) { + /* If the user presses Ctrl-c while the debugger is waiting + for an event, he expects the debugger to interrupt his + program and to get the prompt back. There are two + possible situations: + + - The debugger and the program do not share the console, in + which case the Ctrl-c event only reached the debugger. + In that case, the ctrl_c handler will take care of + interrupting the inferior. Note that this case is + working starting with Windows XP. For Windows 2000, + Ctrl-C should be pressed in the inferior console. + + - The debugger and the program share the same console, in + which case both debugger and inferior will receive the + Ctrl-c event. In that case the ctrl_c handler will + ignore the event, as the Ctrl-c event generated inside + the inferior will trigger the expected debug event. + + FIXME: brobecker/2008-05-20: If the inferior receives the + signal first and the delay until GDB receives that signal + is sufficiently long, GDB can sometimes receive the SIGINT + after we have unblocked the CTRL+C handler. This would + lead to the debugger stopping prematurely while handling + the new-thread event that comes with the handling of the + SIGINT inside the inferior, and then stop again + immediately when the user tries to resume the execution + in the inferior. This is a classic race that we should + try to fix one day. */ + SetConsoleCtrlHandler (&ctrl_c_handler, TRUE); wait_for_debug_event (&m_last_debug_event, INFINITE); + SetConsoleCtrlHandler (&ctrl_c_handler, FALSE); m_debug_event_pending = true; } serial_event_set (m_wait_event); @@ -505,7 +537,11 @@ windows_nat_target::wait_for_debug_event_main_thread (DEBUG_EVENT *event) serial_event_clear (m_wait_event); } else - wait_for_debug_event (event, INFINITE); + { + SetConsoleCtrlHandler (&ctrl_c_handler, TRUE); + wait_for_debug_event (event, INFINITE); + SetConsoleCtrlHandler (&ctrl_c_handler, FALSE); + } return false; }); } @@ -1844,35 +1880,7 @@ windows_nat_target::wait (ptid_t ptid, struct target_waitstatus *ourstatus, while (1) { - /* If the user presses Ctrl-c while the debugger is waiting - for an event, he expects the debugger to interrupt his program - and to get the prompt back. There are two possible situations: - - - The debugger and the program do not share the console, in - which case the Ctrl-c event only reached the debugger. - In that case, the ctrl_c handler will take care of interrupting - the inferior. Note that this case is working starting with - Windows XP. For Windows 2000, Ctrl-C should be pressed in the - inferior console. - - - The debugger and the program share the same console, in which - case both debugger and inferior will receive the Ctrl-c event. - In that case the ctrl_c handler will ignore the event, as the - Ctrl-c event generated inside the inferior will trigger the - expected debug event. - - FIXME: brobecker/2008-05-20: If the inferior receives the - signal first and the delay until GDB receives that signal - is sufficiently long, GDB can sometimes receive the SIGINT - after we have unblocked the CTRL+C handler. This would - lead to the debugger stopping prematurely while handling - the new-thread event that comes with the handling of the SIGINT - inside the inferior, and then stop again immediately when - the user tries to resume the execution in the inferior. - This is a classic race that we should try to fix one day. */ - SetConsoleCtrlHandler (&ctrl_c_handler, TRUE); ptid_t result = get_windows_debug_event (pid, ourstatus, options); - SetConsoleCtrlHandler (&ctrl_c_handler, FALSE); if (result != null_ptid) {