From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by sourceware.org (Postfix) with ESMTPS id BB88C3858D20 for ; Fri, 20 Jan 2023 09:14:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BB88C3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674206067; x=1705742067; h=from:to:subject:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding; bh=K9SxMzjaPYoyVjSQFnJyH/9anade60x/iMFXmjuWNCA=; b=QDgEJZIDfMIYtHqBWVj+ZfrOr1L9hyD4+FGfmPZe+yENgCkkutiUQOBr u+9yu6U+aMwT1N3+PqGyOub0cKjqa5SzBCsMAYL2lSQRS4Y3Z8NC/QV+9 7U5QwdYOLQSuBXwhKWES0APyRzkps5Ca2yDvl0vYFQmsj1h1v9UA+mLL2 D4VrcIYhLtDsj2oFZiiXoA/p7rXpl9O1EGnujgoSJbWDzrLeWxsPnr7rg FO7nhMbSL2+Ymi3YyD8amFO0Ye/2ozrBP7yZUqa0FD9AAZFBmifsWYxbq zYbfhpelzLhBcYVRdEMocLQv8UJMDAMrwdF79F5fX8rdes4fe/9BFvkIN g==; X-IronPort-AV: E=McAfee;i="6500,9779,10595"; a="411772810" X-IronPort-AV: E=Sophos;i="5.97,231,1669104000"; d="scan'208";a="411772810" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2023 01:14:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10595"; a="729053037" X-IronPort-AV: E=Sophos;i="5.97,231,1669104000"; d="scan'208";a="729053037" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga004.fm.intel.com with ESMTP; 20 Jan 2023 01:14:26 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Fri, 20 Jan 2023 01:14:26 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Fri, 20 Jan 2023 01:14:26 -0800 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.42) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Fri, 20 Jan 2023 01:14:26 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G/wHMP0lqnpXnHJUk97RT6W5wKDCRL3HffrwoZ4pGqB7GwNpSP4BHEFWZQ+N2e33BZXv7yxYQHIEOJUp2A/FUOhTwvhcepO6UC5ZTpsLYMiV1nUlQNnxc7EsL4xcVbzgvkVQxJI+x2PIRe/1uol0CjS4FNc+5KvgqqBe+j50HKJ95mlRs5XkN+sn6NarraKtiRXGSKL5fZIxjY+TXxSMz9h96Gx7DLP3lzE+NE2m8cAJBPfH4ETQ2r9KP8wlAY1+iZ+Nkb5NsLLweTFUZ+NbSwRfHM0kRnYHmouPCIXoRL9oSv74pDEdn+mSzI80YCPNnkMJUq9i1MZbLBg7uhWMrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WH8CTwlxIKOdmEo5FkdrrKnECt0i7wQbi/3Fa3DVslg=; b=lfzRMshjVt32Fw7hY8pyh0B44N+E7dI5YigP6PbgD6MiqTy+S89C3oVCSwS7pfiNicKQE4G8nCQLD/0YNLXd6GhsDqqS3A9STJiA/lEaG/XmvkXFGyvvGhBk0BgknuCr1qw2Zgre4LjsvdjqFiskdfg+sXzjwtrXreRA1yAZHDjItD5Rz5uui6JAxlRCLvApGMTgIKwFdTPFUja9rS7SnmZEqk2o3LrzjkrD930D6TN9RxmK91qD8XAFXAFLYGvp4NDDoplAWhDplt3djrMi4UM8OQcYGG7dzpCu4TQMDxtvv9CpJGwELTrO+BSpLf5XTSiyoWItLhbpe/HWtMigiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from DM4PR11MB7303.namprd11.prod.outlook.com (2603:10b6:8:108::21) by DM6PR11MB4531.namprd11.prod.outlook.com (2603:10b6:5:2a5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6002.13; Fri, 20 Jan 2023 09:14:24 +0000 Received: from DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::dec6:d57d:f767:c5f2]) by DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::dec6:d57d:f767:c5f2%4]) with mapi id 15.20.6002.026; Fri, 20 Jan 2023 09:14:24 +0000 From: "Aktemur, Tankut Baris" To: Andrew Burgess , "gdb-patches@sourceware.org" Subject: RE: [PATCHv2 11/13] gdb/remote: avoid SIGINT after calling remote_target::stop Thread-Topic: [PATCHv2 11/13] gdb/remote: avoid SIGINT after calling remote_target::stop Thread-Index: AQHZK1jvJQxkuh2Vs067xf0RM1kaW66nAe6Q Date: Fri, 20 Jan 2023 09:14:24 +0000 Message-ID: References: <167045998eadfcb2015eb0b786e9aab56633b0ab.1674058360.git.aburgess@redhat.com> In-Reply-To: <167045998eadfcb2015eb0b786e9aab56633b0ab.1674058360.git.aburgess@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR11MB7303:EE_|DM6PR11MB4531:EE_ x-ms-office365-filtering-correlation-id: a504d2bc-2a8e-40fa-8259-08dafac6b926 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AymddB4o37lVReG1ac2JqiohdMje5Hj1ZNRk5iD3yU+tp+6++dexyeGQ6dIvQclJcGbrFTT8xe90Z2sfTyFhqpSBDgxlJG6qXE+sGPzPCftQWO9+i2BN5UmesIadFv1V7DkHuetrD6U6ipnJYGRwvil4uS61YckezjWPmTWuqd6Cx7nWcsZwYICq3DYrZ5UiXvNxNV75Ws6ntnxUryKtWzGVrrpy0p1d+dPVG+oV2vKyVdR8q/8UAtc7OM9uzb8DUDmEYVrI9v1aYgpC/LFEY1qp6iBS/wwxwl2/gAwS4XQdAYeLwOqrE+QgkoN7WoOuckJ7H4r/2DZSBIcNRkc22+0R08UmrazulmWbThM9CZevfYeHst19eGP4qZA6il2SkBDcodjrl/Esct0R5orY8exaw2RhXagNlPjJSfwTdtxvYWzny3TtlaFgiaY9OmWEg2E1xS97+Q5AyqoF6oZSN4c/Zf9023GOFdoXF15us7RHayS6PvoWHRvLXgnclagdeTU5MgR4Q32dCq9whbs+dH/758T4i1V0De4YMA0BtaI+tVPGgcPYZUa6w5b7v+92dK3qDelG2HwMhwdJQgzvtlG7cLt1r8Tiat96I0i26SPtl+TlbCWYdwbi2LUh1ldyNTSzFiT5qlvS6gkxpCSUwB8lOiPLa3n5k1QnX9vv+xellwLT9kWGJRDprHc9H/Af8x0pTmuoJ8owUD01tRaOAw== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR11MB7303.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(346002)(396003)(39860400002)(366004)(376002)(136003)(451199015)(2906002)(71200400001)(52536014)(41300700001)(7696005)(110136005)(9686003)(55016003)(316002)(38100700002)(186003)(6506007)(26005)(53546011)(478600001)(82960400001)(8936002)(76116006)(5660300002)(66446008)(64756008)(66946007)(8676002)(66556008)(122000001)(66476007)(33656002)(83380400001)(86362001)(38070700005);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?HRMIpSHDjb5FTIMm2Zq0FgwUgZHlmfNwegVDnVWkOMkG345qiX3BjjcCXRHh?= =?us-ascii?Q?PdruRU1mBzgRXnB4CaaSVZp4ljSKaFA6RgtUzZVXt6VKpPpzqcpoITZROpCz?= =?us-ascii?Q?tDRL1tLJCkQxlYcz2aEe9kmKd/dvIJC4vRqp9W8vhraXneIyuwJzAenlWLbb?= =?us-ascii?Q?yeUcNrxA4yT+x+OW/8Ci73iGyULdOwAwd/F9wUOUWxnWobdjYwTKNZ7TRJ4+?= =?us-ascii?Q?812iFLWOCkoOfxxPtZ5+cx86v+i2aJ/LdeULatnOQuhHxUqheJa/izxN3Wm3?= =?us-ascii?Q?+9C1U8ce2Jl7MrgrTpmPfpDTZrGNEeroSYdB7rm8k/wCxmRYIAagPfPOBiYY?= =?us-ascii?Q?9ukQ2Y/9EXEq+aFf0caUVdzsKEl5bx1Vhomo0ClKVPh1z9uXWKO4Iii+eAoa?= =?us-ascii?Q?Rx7BiaT1ce2B9wxaMgaijhMh7EpfCB1EruTjmnK2nebgvkRJi0WYhUbXJOmF?= =?us-ascii?Q?/8P3H/MHHt7uHWIhvckygN2Ip0EBSWIGNI7oArcck/m4E9XXL20Aficitnno?= =?us-ascii?Q?EscMassykKeaRL0lAiQ51wFcSgQ3QZal4k34ISiYFuGqeAHrNiVxA2y5baag?= =?us-ascii?Q?wmTpSRK7vrpcDWkq9h+cl3VP8HT86xRqW2b1KAayef+Oqz5t9GKuYcYdfclc?= =?us-ascii?Q?tZhzCk5p+v/NneTa6Mz2NM9cv1hMajm1akjygkTB7ZBkvmwQwXxn9GDY+vQr?= =?us-ascii?Q?Nah8TE9ZvdY3XHA30mIWfZ6SrJwiCweD0EEOwNjDu5kH7A9G16xwAGe6hMCR?= =?us-ascii?Q?fvZ0cnL8Ey/pJvMr2kgJcnHtAblXian8IcMPc6q141gw1w/GNv0+ii1kWK1r?= =?us-ascii?Q?1zHZ46whPHkIZ3VZLCpWmuGXpHvtQyETkgI7hDD/0kk7z0ae0kxNztazACMz?= =?us-ascii?Q?ERe3/1EjYtTxCIvacpBymiTIBI0DleharIGgVh5Nh5Mvr0AQM4U6MnJLwCKp?= =?us-ascii?Q?38TSnBVzy2wZ6pQ+ZO/kMJhAbjpt3sAumJUEor/ztyJLJ+AJ/m01wfxxc2j0?= =?us-ascii?Q?xt+uwSnd1a0iu6JO7mIL7Rs/c2tyU7mRDZXcMkxLnn9clUcPJZPWhprlC6L3?= =?us-ascii?Q?0Oz9ZcqRj2WxN+BQbVlQQI8ZN/G35OjOk4TqHMiqj01vsdSvmLLmYW+R+htw?= =?us-ascii?Q?QvLVealBeH7SzQnQ9fBdv8VIJX5B2Vjq+WKyc5XGOObbST495CWVhqEO4KJW?= =?us-ascii?Q?xSnXgh32S0hjCIN1qEt2LeHSFB4+3E9OhqVl1yCZhU+glnd97NE8CkuKvsR1?= =?us-ascii?Q?odpBLXkP3oVnDNOi6XIdRAC5zF0mkWt8tCn6WYIV69MiLPYm6wtfZzf4wzng?= =?us-ascii?Q?i/LHHWDnBudmDvONi0FS+ft1qWeFdnJ6tG8ad0AGrXQj3b9tQ/sa889HplhF?= =?us-ascii?Q?eclnE7zVeUbJ0dcboh3TbY2y2NNmYTMIEpTnVpmBBGE6n9l9buA22xa/W5Ov?= =?us-ascii?Q?jS+20DUFfH9GlIdrzuZvJ758WqWkQ2VOFrAzOIT1Xk4nLSf7hoYfaHeDTYV7?= =?us-ascii?Q?0GO5hAkS00OUxyA9xNEEot5m1XqScT/WWmCfQ4CXijgR0ke3Mx0YuakjUl5d?= =?us-ascii?Q?dks5mXCyea3wSgQ5SS48c8D2Z1Oi+ALpemN6sfV9Rd/c9gbY5WoG/WyKbjAW?= =?us-ascii?Q?Yw=3D=3D?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB7303.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a504d2bc-2a8e-40fa-8259-08dafac6b926 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2023 09:14:24.2799 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 22SWVCrsJn8HcLJ6eLrP+Mq7lAWI4Ib2ck+Key9s4hhLRXNe/dw5vMrXN3I+q92PwHA0IlNjgDDk4lrhStQmlASm5P+dT4sAHvTZrwwe9C0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4531 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_NONE,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 List-Id: On Wednesday, January 18, 2023 5:18 PM, Andrew Burgess wrote: > Currently, if the remote target is not running in non-stop mode, then, > when GDB calls remote_target::stop, we end up sending an interrupt > packet \x03 to the remote target. > = > If the user interrupts the inferior from the GDB prompt (e.g. by > typing Ctrl-c), then GDB calls remote_target::interrupt, which also > ends up sending the interrupt packet. > = > The problem here is that both of these mechanisms end up sending the > interrupt packet, which means, when the target stops with a SIGINT, > and this is reported back to GDB, we have no choice but to report this > to the user as a SIGINT stop event. > = > Now maybe this is the correct thing to do, after all the target has > been stopped with SIGINT. However, this leads to an unfortunate > change in behaviour. > = > When running in non-stop mode, and remote_target::stop is called, the > target will be stopped with a vCont packet, and this stop is then > reported back to GDB as GDB_SIGNAL_0, this will cause GDB to print a > message like: > = > Program stopped. > = > Or: > = > Thread NN "binary name" stopped. > = > In contrast, when non-stop mode is off, we get messages like: > = > Program received SIGINT, Segmentation fault. > = > Or: > = > Thread NN "binary name" received SIGINT, Segmentation fault. > = > In this commit I propose a mechanism where we can track that a stop > has been requested for a particular thread through > remote_target::stop, then, when the stop arrives, we can convert the > SIGINT to a GDB_SIGNAL_0. With this done GDB will now display the > "stopped" based messages rather than the "received SIGINT" messages. > = > Two of the tests added in the previous commit exposed this issue. In > the previous commit the tests looked for either of the above > patterns. In this commit I've updated these tests to only look for > the "stopped" based messages. > --- > gdb/remote.c | 17 +++++++++++++++++ > gdb/testsuite/gdb.base/infcall-timeout.exp | 9 +-------- > .../infcall-from-bp-cond-timeout.exp | 9 +-------- > 3 files changed, 19 insertions(+), 16 deletions(-) > = > diff --git a/gdb/remote.c b/gdb/remote.c > index 218bca30d04..61781a24820 100644 > --- a/gdb/remote.c > +++ b/gdb/remote.c > @@ -1139,6 +1139,10 @@ struct remote_thread_info : public private_thread_= info > std::string name; > int core =3D -1; > = > + /* Only used when not in non-stop mode. Set to true when a stop is > + requested for the thread. */ > + bool stop_requested =3D false; The thread_info struct already has a `stop_requested` field. Why can't we = use it? > /* Thread handle, perhaps a pthread_t or thread_t value, stored as a > sequence of bytes. */ > gdb::byte_vector thread_handle; > @@ -7114,6 +7118,12 @@ remote_target::stop (ptid_t ptid) > /* We don't currently have a way to transparently pause the > remote target in all-stop mode. Interrupt it instead. */ > remote_interrupt_as (); > + > + /* Record that this thread's stop is a result of GDB asking for the > + stop, rather than the user asking for an interrupt. We can use > + this information to adjust the waitstatus when it arrives. */ > + remote_thread_info *remote_thr =3D get_remote_thread_info (this, p= tid); > + remote_thr->stop_requested =3D true; > } > } > = > @@ -8097,9 +8107,16 @@ remote_target::process_stop_reply (struct stop_rep= ly *stop_reply, > /* If the target works in non-stop mode, a stop-reply indicates that > only this thread stopped. */ > remote_thr->set_not_resumed (); > + gdb_assert (!remote_thr->stop_requested); > } > else > { > + if (status->kind () =3D=3D TARGET_WAITKIND_STOPPED > + && status->sig () =3D=3D GDB_SIGNAL_INT > + && remote_thr->stop_requested) > + status->set_stopped (GDB_SIGNAL_0); > + remote_thr->stop_requested =3D false; > + > /* If the target works in all-stop mode, a stop-reply indicates that > all the target's threads stopped. */ > for (thread_info *tp : all_non_exited_threads (this)) > diff --git a/gdb/testsuite/gdb.base/infcall-timeout.exp b/gdb/testsuite/g= db.base/infcall- > timeout.exp > index a5b0111ed04..bd6b2bfac3e 100644 > --- a/gdb/testsuite/gdb.base/infcall-timeout.exp > +++ b/gdb/testsuite/gdb.base/infcall-timeout.exp > @@ -45,16 +45,9 @@ proc_with_prefix run_test { target_async target_non_st= op } { > = > gdb_test_no_output "set direct-call-timeout 5" > = > - # When non-stop mode is off we get slightly different output from GD= B. > - if { [gdb_is_remote_or_extended_remote_target] && $target_non_stop = =3D=3D "off" } { > - set stopped_line_pattern "Program received signal SIGINT, Interrupt\\." > - } else { > - set stopped_line_pattern "Program stopped\\." > - } > - > gdb_test "print function_that_never_returns ()" \ > [multi_line \ > - $stopped_line_pattern \ > + "Program stopped\\." \ > ".*" \ > "The program being debugged timed out while in a function called f= rom GDB\\." \ > "GDB remains in the frame where the timeout occurred\\." \ > diff --git a/gdb/testsuite/gdb.threads/infcall-from-bp-cond-timeout.exp > b/gdb/testsuite/gdb.threads/infcall-from-bp-cond-timeout.exp > index 3341ff33f19..9ba38e6896a 100644 > --- a/gdb/testsuite/gdb.threads/infcall-from-bp-cond-timeout.exp > +++ b/gdb/testsuite/gdb.threads/infcall-from-bp-cond-timeout.exp > @@ -92,16 +92,9 @@ proc run_test { target_async target_non_stop other_thr= ead_bp } { > "get number for segfault breakpoint"] > } > = > - # When non-stop mode is off we get slightly different output from GD= B. > - if { [gdb_is_remote_or_extended_remote_target] && $target_non_stop = =3D=3D "off" } { > - set stopped_line_pattern "Thread ${::decimal} \"\[^\r\n\"\]+\" received= signal > SIGINT, Interrupt\\." > - } else { > - set stopped_line_pattern "Thread ${::decimal} \"\[^\r\n\"\]+\" stopped\= \." > - } > - > gdb_test "continue" \ > [multi_line \ > - $stopped_line_pattern \ > + "Thread ${::decimal} \"\[^\r\n\"\]+\" stopped\\." \ > ".*" \ > "Error in testing condition for breakpoint ${bp_num}:" \ > "The program being debugged timed out while in a function called f= rom GDB\\." \ > -- > 2.25.4 Regards -Baris Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva = Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928