From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by sourceware.org (Postfix) with ESMTPS id 2CF033858D37 for ; Wed, 28 Jun 2023 10:15:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2CF033858D37 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=1687947315; x=1719483315; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=y6dJgVJu9KgK6hHJ8EhPexmYfSBXcuqHugtbdz1z0S8=; b=DZtRUfrFjtPBUn2A1nXqgXDwHGTNuygpt/CCvMmA1WE9mIQu/Yi9CJwF HiT9A2eLWywm8S7JW0fFLlkVYTg4XPn8KfRIkiAmZLX2JI9aekYkUWjd6 Q3rIsAsnP9IqMbhX9Zt4jej+41e3qrXzqVgW41J5mvuegiLpHwimlWfzD gFNeAyLs6GErz6X7bbqEFmgpCwn+CNp1+2i13yspaAKVSqLcItzxLsizK MR+I03yi2AFv78cdbPCz4KOhSHapWcV8AjQ72+ewQdstSGOifFRNaeVS7 s1Q5w9JzDnkEpukDllAHpRAHdvOzwFUXCtP8eawB7vA0kNDS3ZcWyXJnu g==; X-IronPort-AV: E=McAfee;i="6600,9927,10754"; a="365265653" X-IronPort-AV: E=Sophos;i="6.01,165,1684825200"; d="scan'208";a="365265653" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2023 03:15:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10754"; a="782229781" X-IronPort-AV: E=Sophos;i="6.01,165,1684825200"; d="scan'208";a="782229781" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmsmga008.fm.intel.com with ESMTP; 28 Jun 2023 03:15:11 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Wed, 28 Jun 2023 03:15:03 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Wed, 28 Jun 2023 03:15:03 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27 via Frontend Transport; Wed, 28 Jun 2023 03:15:03 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.169) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.27; Wed, 28 Jun 2023 03:15:01 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Fr41IubxMp4pBh+FiY2g8YU4HW31obC3XZrsYbDYozYAlxnuQxjUxHvyfu1PdYXo4grKITW8ptOXANr+GWoNLD16687AFcdQ+nUJLl05VO6LcMNmpu4HEHtK6yzLfuIPbfK6pt2DNVs4QcJcxRJp7MCiDufnW/WDmvpMndCmcYZFzkemAIIL4mvNm/iDT8L3M1O8+Ayhsw4ZbYSj+OfOERG2MK7CNqAJMQYJQ9ZXFZJmBTAm2pl3uE07ojSaOa4SDeA0vgRMo3ci8OlKNyos3QrrWtrwOfDCKs9OeM1d913hODVUJeQIVb2kY/ln+gcRbVOj3Qf0g+4DonQK5fIdJA== 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=krj/t+5FNN+ymO7UJe3xuWxAHDsMahOH2yYOd6yB45c=; b=aHXKO16PP0HrdkzbgBgIy4qHuF1ZCq0HlbG0n9zc39haYycHzd05n3Tzwru9aqOxd5nteVhNAnh8Ru5B50JWD6yMsD0Xi7w2sorcSemDAyyziWs0AJ1jkZEJIc5scCtmBBIfVQfhOfF1is+YJyy/nUFDg4Er8V4j33KdGoiEd8H75JCNQC5L7QwfJvfDKae3saZHCFLUD+w2X+F2ULX3ZoiDwmB4nypkN6gqMd87nlLfRzhuTfsjMP2dPdYAukX2T1JtjSmZ9pLDx/9JaqgFhpBwxmWbCBZgQaGdWhWG0DSbMFtQWoxIjLvjZYo0baePvwYVz9n6mgZVzvKnsZP/Jg== 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 CY4PR11MB2005.namprd11.prod.outlook.com (2603:10b6:903:2e::18) by DM4PR11MB5565.namprd11.prod.outlook.com (2603:10b6:5:39e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6521.24; Wed, 28 Jun 2023 10:14:59 +0000 Received: from CY4PR11MB2005.namprd11.prod.outlook.com ([fe80::b405:9025:f19c:90c1]) by CY4PR11MB2005.namprd11.prod.outlook.com ([fe80::b405:9025:f19c:90c1%5]) with mapi id 15.20.6521.026; Wed, 28 Jun 2023 10:14:59 +0000 From: "Schimpe, Christina" To: Andrew Burgess , "gdb-patches@sourceware.org" CC: "blarsen@redhat.com" , Simon Marchi Subject: RE: [PATCH v2 1/1] gdb, infrun: refactor part of `proceed` into separate function Thread-Topic: [PATCH v2 1/1] gdb, infrun: refactor part of `proceed` into separate function Thread-Index: AQHZnQKTw4EvIoFAT0KNQEqGX00qiq+KFLGAgAMhSwCACbosAIAJJHzA Date: Wed, 28 Jun 2023 10:14:58 +0000 Message-ID: References: <20230612074927.424961-1-christina.schimpe@intel.com> <20230612074927.424961-2-christina.schimpe@intel.com> <87pm5yweda.fsf@redhat.com> <87edmbwxap.fsf@redhat.com> <87y1kbshih.fsf@redhat.com> In-Reply-To: <87y1kbshih.fsf@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: CY4PR11MB2005:EE_|DM4PR11MB5565:EE_ x-ms-office365-filtering-correlation-id: 3bb7064a-4fe6-4310-e104-08db77c0873a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mmQLlFPzclHj/jft4e24nykulr2RPuw+hTNkb7X/OxviEohGBBUKXJJmew20NHZJjPYQ8u/IvbPbtRb9Qe25M2GV3N6a5ALdRfT9uQV9EDfPUFpqOmNWnhD9M7An7hcQpqfB2KjX+7mbLW58AkkdSbLcw7AGFZQtXXbpJHlptGA9vq18xUoH68fFU5zlH0ytgwL4pMoQHyav9qYlSMtLoLNt3jzxMrMk0Lm1JsugVzAGNlsjWrXjWp/9Vr5+TYFkaeaZtEW+oTsDFOUUGO0xgUtlrjYI5dTZIrQ5P0Gznps3F1lXFt9uhOo+JsIYSJDZ5STE2Qj7SL7OcRZ3JjalQfN5uGe/1TUwq8aTEopKeFskwVUwxEna5pOad8sKUa7hcbkuIC1W3ruukJiDCgEjpcL/BAQySed2tiQmXGcfJldMzfSAGSjQ2nKiYBSEtSozXIv7eom5fVq8ehrl1+akdgCVj6yELtXu/63exI/RpE7ZxzJHD4zwb1QIxCZH0ImEKoRt9zzcaAHUiIIU7acOahW/uvZp2iNFzbGrmZh2F7K/lrjKdv8WGYwNkNpW3Y5WbQ9fsivAlFwo7bO9kua6hDFVVHB3Z/OPLB1cxAdQ7mgu4IugsHvvmLL/aBBReinr x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CY4PR11MB2005.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(136003)(366004)(39860400002)(396003)(346002)(376002)(451199021)(26005)(33656002)(122000001)(52536014)(86362001)(41300700001)(38070700005)(64756008)(66556008)(82960400001)(4326008)(66946007)(66476007)(8936002)(316002)(76116006)(38100700002)(8676002)(66446008)(55016003)(110136005)(966005)(5660300002)(6506007)(53546011)(9686003)(186003)(71200400001)(83380400001)(54906003)(7696005)(2906002)(478600001)(81973001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?EKhVE8ZBw5ghEULwFQXXHWpjxXuHsdCERD8kchKuFXL43teq3y4mh6/4H1XZ?= =?us-ascii?Q?1kvj4XXQ/m2rZZmRP1KX+ZHF9IMxPFu0XdnUZReh6ukxvz2mWgQbkNELCHn+?= =?us-ascii?Q?Xf7TeeROUeon36TA6RD+uD6I87M6VUnURHB9vtOCNOIfsnwH9NjqI4QGUbam?= =?us-ascii?Q?spxUCjdDY09+fkfjRLCDC5N2wesZLTl0vy0XANcM+HsDtGifvzfvE0Lzps7x?= =?us-ascii?Q?HlZGbySpaoMZeNiXHXj+4AzBfIZZiOzYlqD1QEGbWdlzmoAvVEy3jwsJ8oKW?= =?us-ascii?Q?NQCSf7xmSWR/BLRDvnvh3LTyXbPb+kclE2RLhadV8zbtdR6RpSqkMAhHQEhC?= =?us-ascii?Q?KcAi0a8mM0L3/UXaZXkO8Bhye71psgIXTxXHGy7p5wThESZ7jfGrTfATpHh0?= =?us-ascii?Q?ndWR8vwgoiijKaOf7RShZwDRpqIkLGCbUrNNzOLAnPeFG3OxwPx9JaD2wsPd?= =?us-ascii?Q?gde3ch+1XOxnojhMua5djisozc3+00vi1i3KjESBNB5aHXl/6IUbY8xEyv6h?= =?us-ascii?Q?sIJV9cggfaG04DiJQZJFuZcFW9M6bQKgZLa4CTxrjxuY5V7D91AQbLOzywuh?= =?us-ascii?Q?5bWRoyICqFHaeQO/vNMgcpW4DATViTidDTbeoeW55w7Lc7axkbpm464BBz/V?= =?us-ascii?Q?tupClTOfqRBX/lWfpHkHjwqhXX8KEhjHsCwSap7Pe0Mi83jOFkQYd3zNh4tY?= =?us-ascii?Q?CYNtc8DDJq9QPsGn2NnmO5BacI6dMvASdOv3Bfz5p/QpkblhkDtFRCmhXwJP?= =?us-ascii?Q?TLXOcDCzs3OuJ9TM6UJr65fex5r/Bn5OOZueq2Vvx7sL/e3Z8J4zeyLVUVyC?= =?us-ascii?Q?YBN4OFh5ewxY8wnL36j/Mh2Pr2Z4zX+SyJhaovfElyo0DXHFbcHcbURvrqN1?= =?us-ascii?Q?OPl+nJYKj5eQdoH/UBh5t3oVKVhv5EjMpMB0ZxixH6LUBvgpEGrrQGdQDRlP?= =?us-ascii?Q?FslR+lFgaunBlf7cnG3noqE3E64QLC0/MyAFD1r1mVPRYDwXhqmbaNfhcc2U?= =?us-ascii?Q?EVLmFaRvA9aszB1PSgKAWWhr2E1yr6oRw3TRRKx6BXUMIyfimh4nMnEOm+nm?= =?us-ascii?Q?2kntbbIhrRmYwglLgYumwH0GygtqYF8rsg/Z+EXztUwYY+WTgrRxeaHz5eKr?= =?us-ascii?Q?i+fdvxudJsr7etqFENbxpYH9AcN/Rme97rufFahi0DxwCzA5hIkAQuUGBucG?= =?us-ascii?Q?jYXd+MqfA9cMb6UDBCPT0dDSSE+X+Yyq0Ic2JwVCII4NXGgma9t39wCcg71J?= =?us-ascii?Q?RRMHFEQR2qoNIdB4slgDLZOiiiE91bPnc0AYt5npkOh6sE8eCckq+HqpiOR2?= =?us-ascii?Q?MBtgJRiCc9hxLmHvbLjlfi7VN+fwc+lRmOC98bjYREZao55e3OgyoEZWRYy/?= =?us-ascii?Q?kHGYAdFeY0C6AkcFPSYVVivBfSwbthnGjP4MvfsaAlO6jrGsgn++eQ7haY0U?= =?us-ascii?Q?RulqXI7zsLkcKecP2Q6XMuURVkwrAJsKWtZflHOYfQJKwoTkhTeO/NKvRtIT?= =?us-ascii?Q?49P/SnjxM4lfUwTrCjjmqqeQHyyLPurrcxvw9v9pmJFnq/55/cSKDBkJ/WvG?= =?us-ascii?Q?k3s99PjCPHifqXA+lORNTuo8Iq7SWb6PdKcjlOjD?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR11MB2005.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3bb7064a-4fe6-4310-e104-08db77c0873a X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2023 10:14:58.9007 (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: HLpBmIpdLcRApPPfxVvzq4z/FvhrZX6NVK+yFy/ePIIdvMu4Fxpl7n6AeOpL+fRNKvLxP9py31aUTOn2c9UZdtEt4fdFoBwPVtMdaajrzvI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5565 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-10.5 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,T_SCC_BODY_TEXT_LINE 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: Hi Andrew, = So sorry for my late response. Unfortunately, I could not have a look at it= earlier and it also took me some time. >> I tried to like this merged logic block, but I just couldn't. So in the >> end I went back to the original commit: >> >> commit d8bbae6ea080249c05ca90b1f8640fde48a18301 >> Date: Fri Jan 14 15:40:59 2022 -0500 >> = >> gdb: fix handling of vfork by multi-threaded program (follow-fork-= mode=3Dparent, detach-on-fork=3Don) >> >> And tried to understand what's going on. The commit message on that >> original commit is awesome, and well worth a read. I totally agree. I tested the latest version of your patch and it lgtm. Thanks, Christina > -----Original Message----- > From: Andrew Burgess > Sent: Thursday, June 22, 2023 4:23 PM > To: Schimpe, Christina ; gdb- > patches@sourceware.org > Cc: blarsen@redhat.com; Simon Marchi > Subject: Re: [PATCH v2 1/1] gdb, infrun: refactor part of `proceed` into > separate function > = > Andrew Burgess writes: > = > > Andrew Burgess writes: > > > >> Christina Schimpe writes: > >> > >>> From: Mihails Strasuns > >>> > >>> Split thread resuming block into separate function. > >>> > >>> Co-Authored-By: Christina Schimpe > >>> --- > >>> gdb/infrun.c | 120 > >>> ++++++++++++++++++++++++++------------------------- > >>> 1 file changed, 61 insertions(+), 59 deletions(-) > >>> > >>> diff --git a/gdb/infrun.c b/gdb/infrun.c index > >>> 58da1cef29e..ec41b658864 100644 > >>> --- a/gdb/infrun.c > >>> +++ b/gdb/infrun.c > >>> @@ -3268,6 +3268,64 @@ check_multi_target_resumption > (process_stratum_target *resume_target) > >>> } > >>> } > >>> > >>> + /* Helper function for `proceed`. Check if thread TP is suitable = for > >>> + resuming, and, if it is, switch to the thread and call > >>> + `keep_going_pass_signal`. If TP is not suitable for resuming t= hen > >>> + this function will just return without switching threads. */ > >> > >> The indentation here is wrong -- header comments should start in the > >> first column > >> > >>> + > >>> +static void > >>> +proceed_resume_thread_checked (thread_info *tp) { > >>> + if (!tp->inf->has_execution ()) > >>> + { > >>> + infrun_debug_printf ("[%s] target has no execution", > >>> + tp->ptid.to_string ().c_str ()); > >>> + return; > >>> + } > >>> + > >>> + if (tp->resumed ()) > >>> + { > >>> + infrun_debug_printf ("[%s] resumed", > >>> + tp->ptid.to_string ().c_str ()); > >>> + gdb_assert (tp->executing () || tp->has_pending_waitstatus ()); > >>> + return; > >>> + } > >>> + > >>> + if (thread_is_in_step_over_chain (tp)) > >>> + { > >>> + infrun_debug_printf ("[%s] needs step-over", > >>> + tp->ptid.to_string ().c_str ()); > >>> + return; > >>> + } > >>> + > >>> + /* There are further two scenarios for which we must not resume the > thread: > >>> + - If a thread of that inferior is waiting for a vfork-done > >>> + (for a detached vfork child to exec or exit), breakpoints are > >>> + removed. We must not resume any thread of that inferior, oth= er > >>> + than the one waiting for the vfork-done. > >>> + - In non-stop, forbid resuming a thread if some other thread of > >>> + that inferior is waiting for a vfork-done event (this means > >>> + breakpoints are out for this inferior). */ > >>> + if (tp->inf->thread_waiting_for_vfork_done !=3D nullptr > >>> + && (tp !=3D tp->inf->thread_waiting_for_vfork_done > >>> + || non_stop)) > >>> + { > >>> + infrun_debug_printf ("[%s] another thread of this inferior is " > >>> + "waiting for vfork-done", > >>> + tp->ptid.to_string ().c_str ()); > >>> + return; > >>> + } > >> > >> I tried to like this merged logic block, but I just couldn't. So in > >> the end I went back to the original commit: > >> > >> commit d8bbae6ea080249c05ca90b1f8640fde48a18301 > >> Date: Fri Jan 14 15:40:59 2022 -0500 > >> > >> gdb: fix handling of vfork by multi-threaded program > >> (follow-fork-mode=3Dparent, detach-on-fork=3Don) > >> > >> And tried to understand what's going on. The commit message on that > >> original commit is awesome, and well worth a read. > >> > >> After looking at that for a while I think I have a replacement for > >> this block, which I think achieves the same thing, but is structured, > >> and commented slightly differently. > >> > >> I've included an updated version of this patch below, I'd love to > >> hear what you think? > >> > >> The patch below is only partially tested at this point. I'm a little > >> short of time right now. But it passes all the vfork related tests > >> that I've been looking at, so I'm reasonably sure it's OK, I just > >> wanted to get this out so you could take a look at it. > >> > >> Thanks, > >> Andrew > >> > >> --- > >> > >> commit 45460db250f116956f4d75376f6637d2e4e7632f > >> Author: Mihails Strasuns > >> Date: Mon Jun 12 09:49:27 2023 +0200 > >> > >> gdb, infrun: refactor part of `proceed` into separate function > >> > >> Split the thread resuming code from proceed into new function > >> proceed_resume_thread_checked. > >> > >> Co-Authored-By: Christina Schimpe > >> > >> diff --git a/gdb/infrun.c b/gdb/infrun.c index > >> 58da1cef29e..7e6104ffab2 100644 > >> --- a/gdb/infrun.c > >> +++ b/gdb/infrun.c > >> @@ -3268,6 +3268,90 @@ check_multi_target_resumption > (process_stratum_target *resume_target) > >> } > >> } > >> > >> +/* Helper function for `proceed`. Check if thread TP is suitable for > >> + resuming, and, if it is, switch to the thread and call > >> + `keep_going_pass_signal`. If TP is not suitable for resuming then= this > >> + function will just return without switching threads. */ > >> + > >> +static void > >> +proceed_resume_thread_checked (thread_info *tp) { > >> + if (!tp->inf->has_execution ()) > >> + { > >> + infrun_debug_printf ("[%s] target has no execution", > >> + tp->ptid.to_string ().c_str ()); > >> + return; > >> + } > >> + > >> + if (tp->resumed ()) > >> + { > >> + infrun_debug_printf ("[%s] resumed", > >> + tp->ptid.to_string ().c_str ()); > >> + gdb_assert (tp->executing () || tp->has_pending_waitstatus ()); > >> + return; > >> + } > >> + > >> + if (thread_is_in_step_over_chain (tp)) > >> + { > >> + infrun_debug_printf ("[%s] needs step-over", > >> + tp->ptid.to_string ().c_str ()); > >> + return; > >> + } > >> + > >> + /* When handling a vfork GDB removes all breakpoints from the progr= am > >> + space in which the vfork is being handled, as such we must take = care > >> + not to resume any thread other than the vfork parent -- resuming= the > >> + vfork parent allows GDB to receive and handle the 'vfork done' > >> + event. */ > >> + if (tp->inf->thread_waiting_for_vfork_done !=3D nullptr) > >> + { > >> + if (target_is_non_stop_p ()) > >> + { > >> + /* For non-stop targets, regardless of whether GDB is using > >> + all-stop or non-stop mode, threads are controlled > >> + individually. > >> + > >> + When a thread is handling a vfork, breakpoints are removed > >> + from the inferior (well, program space in fact), so it is > >> + critical that we don't try to resume any thread other than the > >> + vfork parent. */ > >> + if (tp !=3D tp->inf->thread_waiting_for_vfork_done) > >> + { > >> + infrun_debug_printf ("[%s] another thread of this inferior is " > >> + "waiting for vfork-done", > >> + tp->ptid.to_string ().c_str ()); > >> + return; > >> + } > > > > This actually fixes a bug that exists currently in GDB. I'm working > > on a patch which includes a test that exposes the bug. I plan to get > > the bug fix merged before we merge this refactoring commit. > > > >> + > >> + /* In non-stop mode we will never end up trying to proceed the > >> + thread that is handling a vfork. When we realise that a > >> + thread is handling a vfork we immediately stop all the other > >> + threads, and resume the vfork parent thread. As far as the > >> + user is concerned, the vfork parent thread is running. Any > >> + attempt by the user to interrupt the vfork parent will be > >> + deferred until the vfork has completed, at which point the > >> + parent will no longer be waiting for a vfork. */ > >> + gdb_assert (!non_stop); > > > > And this assertion is not correct. Again, the new test I'll add will > > trigger this assert. > > > > We can get this refactor merged once my bug fix has landed. I'll > > follow up once I have something posted. > = > I finally got my vfork patches on the mailing list. In the end it felt m= ore natural > for this refactor to live part way through that series, so that's what I'= ve done. > You can see the series here: > = > https://inbox.sourceware.org/gdb- > patches/cover.1687438786.git.aburgess@redhat.com/ > = > Thanks, > Andrew 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