From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by sourceware.org (Postfix) with ESMTPS id EAF3D3858D1E for ; Mon, 19 Jun 2023 16:46:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EAF3D3858D1E 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=1687193169; x=1718729169; h=from:to:subject:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding; bh=vwPTsm8MS5jSRde2vLPTC8y8flGiyFEcuNQcGt53M9E=; b=e6fxK8C8ildqaKGHqOEEoztfQE4MxbMaQhdm/xnAAkfcmNqHbMywImO3 izIuTSngRWnj4HJYPNUrSGP7TX6t0M9biY3MOn7PQUwmOZ3UVz77x1pPt MgWuxgQt4YpKPpjMv8PZGErB9trqtkvbLmnekE0xkHnVqsJn6w4S9+eom ev0jJItgWp3S17nP1sYQMJjmmTnKV3HKaMdC93atqKjiOsXQ1TKm2T2Yu kPu/GslJlUgIYxeFujkpBND0JwCrYy1MaUp5gQwss66/I10rYoDJRGB+I 4g4+TIVADpqjXUD2s7XSP6o5h02xWBOjpEBR/TiYLPmfBf/mrQbRvQNZb g==; X-IronPort-AV: E=McAfee;i="6600,9927,10746"; a="344421505" X-IronPort-AV: E=Sophos;i="6.00,255,1681196400"; d="scan'208";a="344421505" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jun 2023 09:46:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10746"; a="826646483" X-IronPort-AV: E=Sophos;i="6.00,255,1681196400"; d="scan'208";a="826646483" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmsmga002.fm.intel.com with ESMTP; 19 Jun 2023 09:46:08 -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.23; Mon, 19 Jun 2023 09:46:07 -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.23; Mon, 19 Jun 2023 09:46:07 -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.23 via Frontend Transport; Mon, 19 Jun 2023 09:46:07 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.177) 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.23; Mon, 19 Jun 2023 09:46:06 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D+l1lBWILFVlu7pzftGxBFjHO7UXxuKU+Ht95184vz5sq1EocDNENOA9u1aU9JaYGcdyilVXkYatjNa2ojsDtxPBdM7E925nsakOrSCK98QJdtEPPjLI8+9fAlU12YDg9SQuW2+OHrWmm3S2J+BeaiVcZedzvYuePuXxW/0s/Ip0t7UD9t4JYU8doC5nKewdMKMb5Ta4QlV8YuA+beQnv1za4fwd+BHS2jXRKZDcM6jVtTIb5BznZNxXuHdnJSXvlPPOBs2XajeEH5hE2kMFEhZaBRvyjJmn76kBRLiyvqmgs1wslMzY63f0pLvs9Mz1eCC+fl4hgRqkABmnRqajcg== 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=9zPhUWoppnfGhutrCUJfsiC+aQhVIdboVBWSq2ZRhTo=; b=XZXvjAKBqhvZLAFitLy1bJHHwxASk/hkc3bzwdf/6yBJXADjJEDGJ/wvl6TIzIO+VGfvUK3lDhHiX1sVPiANXF3rFblAtR8UUEy3qPSVbpiHCelXIRwCexL31nOYgGtcwJYHTb9Jb0r5+vcYhKEibQpDzMjAfu4rm7ztf63OWYX/hM0nT5asVcK95/2RXNDQE+UVa5Rq2jjGgfUZ9iQ1Rz2Hj74QMxHUSQe1mgOrZtiB4ORhQEMszjdXB88634FS4A4BceHcmjYUsN2QHxl8kFyV4YVOgzQNCRnEdRTAWfeMX34XGLpWABH94ZtzqePyLmDJgs0lLj/d0VbtQZGrNg== 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 SA3PR11MB8022.namprd11.prod.outlook.com (2603:10b6:806:2fe::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6455.32; Mon, 19 Jun 2023 16:46:05 +0000 Received: from DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::e57e:3584:99ad:d384]) by DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::e57e:3584:99ad:d384%7]) with mapi id 15.20.6500.036; Mon, 19 Jun 2023 16:46:04 +0000 From: "Aktemur, Tankut Baris" To: Andrew Burgess , Pedro Alves , "gdb-patches@sourceware.org" Subject: RE: [PATCH 2/2] gdbserver: track current process as well as current thread Thread-Topic: [PATCH 2/2] gdbserver: track current process as well as current thread Thread-Index: AQHZd33wCsp7lr1F7EiU08OZaT3L+q89H65QgFWL/HA= Date: Mon, 19 Jun 2023 16:46:04 +0000 Message-ID: References: <20220419224739.3029868-1-pedro@palves.net> <20220419224739.3029868-3-pedro@palves.net> <87v8hkawun.fsf@redhat.com> In-Reply-To: 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_|SA3PR11MB8022:EE_ x-ms-office365-filtering-correlation-id: a5ad409d-caa9-47d8-98f9-08db70e4ac4b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YUrLFJgyEkeDJUlytTw445DDiQusvZPEQ0Qnak6E+O8IhGRLH6UOpa/rC1/2+CS59hYuyFTqO50/AIkKM9F4yZaq5mtY4BhFhGtV2mQQP7XkMXtpYIn3JnUNzqJ5tVamJk+ddxwUxemyhyKiw+yYvis+odmxvQ9gD3uXoM6avxpaO7CeLHfJGsW8YfYGS234U194IHgKADTStl5l14nJmd4ZmjsgLNVV3nP6UEFKzU0i8RjRmAES55ZzeOIGGsMia501Cfms3x3XZ03Nqqc7oFMU8GBWh0oOOFj32nGWY87QQIXK8kcbj10PgEYEYcYnimAOc4n2qgYGDpRao6DZ1heC+MKhHOIe/NSNuJ5JIDE4Y9b9yCE/cPOQR8Mly45JVhE56IoiqKKK809kI550skxBT0n+fmL856yH9oO49aGavEq8sHAFzrEj+Wrv1HwixieCai6fBKJ0FPrTypQBoriCwu64j7ishBL1Zg3kmI6Wtfarb042+ZCzT2sACrM+zolyBHeSv7M76GKIli//u5tofKmRzvXQu1wahwaYp7cUH/xOge/x6X8UyCTVVQYNQMvbM4eX/Fnl8FTpRrDEtKdtJxO7zEgxLJ1pj1St3H4= 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:(13230028)(39860400002)(136003)(396003)(346002)(366004)(376002)(451199021)(86362001)(33656002)(2906002)(38070700005)(84970400001)(55016003)(186003)(83380400001)(26005)(7696005)(966005)(52536014)(6506007)(9686003)(71200400001)(110136005)(66446008)(122000001)(76116006)(478600001)(66946007)(316002)(41300700001)(64756008)(8676002)(38100700002)(66556008)(8936002)(82960400001)(66476007)(5660300002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/wPpgb0s2lvBnpOOxwIktIdfl7Yi12U5a+FAH0H9mM7ZSYwT5RbOObwhbcZk?= =?us-ascii?Q?ifan01x45Fwzgm7lkILcOLMkJ5fbClRqVQVSwHJyozmRCOaOuLsN+iOHaaen?= =?us-ascii?Q?GRZAiOekVDuAneEs43GT03ReWY8vys71L6mKkr64Hdbru+fuU2OF6fe+Xxdt?= =?us-ascii?Q?26zmoGl8x9aLxo4nMx3Kqa++SZl93wEAyt/ovN+JIFjwJp51wtKBEPWVjHYB?= =?us-ascii?Q?8l/jCr8HSifuIJ9j3qW/qTXDlLg42a+IwUcqCDp76PEEvi7JmWHs9sXUatlp?= =?us-ascii?Q?nzk2gkUFgBQ71jaWCqE40RcV6jSNXgRJBKHhwaFOnPselIpLuuXRZGnC9y2N?= =?us-ascii?Q?Cd5ec3oJrjJ3ZotwLUE1Cp2aVFmAZDN4p7ufdsC+Q32ltnpDZVtL74Np6pmL?= =?us-ascii?Q?MXHAQz18nP9u89vVduHWua2Ms4xvncgB1sRWgS3dTTtYnGDCBLD7f+HdLcYp?= =?us-ascii?Q?q1+yJErT9HnJTWSlT1FV7yOV6YIssxDqYRt6H4tAkOOwcz6hUZHQ/UPIUYl4?= =?us-ascii?Q?cVvUmVYf9SceRWjVykthTKtL0Tp33q3wYBO9OoGzJUO61tkPWnAtBdK4LhYH?= =?us-ascii?Q?uX1zKyvqmWU+U6BgkRMtGk8+9/WvzRFrqxBd/EDKWZH+/gm66WTEnqi7Sih0?= =?us-ascii?Q?f4S+Pm+x9VnJhweIAF2pECyaPRJCDO640O0iofHJY71go0p03R8B/O6Cc7Dr?= =?us-ascii?Q?tFCvAfNxzmy38O7hRJ6KugzJOFxRglLYruck7tcs6blCwHbXnhIYpfHIwaK7?= =?us-ascii?Q?DAr4+S2BXugM2fJVAaQlkVzYouzMWFHfMqVD48DHXltnfWdVFcJ+0fe+AmG9?= =?us-ascii?Q?mbUHB4dX/WgO2ABkTJqGePHyXON+q1uRiOFhe+UXdOlPrXIq/Zb3WUOXvmye?= =?us-ascii?Q?lPZeGyMkGQFbrD5b6npPUDKKWRliOaTjgr1jMfM8nUUbew8odm/Gki9MxhyE?= =?us-ascii?Q?cFm9uuVzYZcQmNCXqgKfO+1jrjOA2sFimTSRXNoIBMWOtd5xsW5x5s/lPpkl?= =?us-ascii?Q?5wua6Jn+Io2lT6KHSUGyh52UT8Yli2BpJFnTchB1VFWc/1QYf1UVRqB/85dy?= =?us-ascii?Q?yvXbRfD3Rk7Tl7gpz5dSF60fhieS8+dMmvyaTLqb4iCCsqjY6lOL6cSky4Eh?= =?us-ascii?Q?xpfcJt6LclTbG3l4NLxR9z6Q69g6BbVEkGXslqSjONgh62aQHoQ0lBUalCXP?= =?us-ascii?Q?UzFLLuoBMZVr0zAXRhcusTUUCpnrvnMXIC7QzC2hqHOf65tx5K1SfDgtXx6W?= =?us-ascii?Q?eA9nv9w2R/lKMUX4r1TxPOTafQR+bYljBDnxzoIFefkcPX32Pfd5/ySDdcH8?= =?us-ascii?Q?GyyCQrzGIEhXrKBa4UBwDOWW4w9KXJcOIIsxpOKdIk8B669K9ReiDTOquYzw?= =?us-ascii?Q?gk4UaOXE6HJ1SF37YyIoHRV+BwxNuAFt3mw0SRgYXS35C3RdCinRvAQoDc3e?= =?us-ascii?Q?r+6ARUU9z3rd24IPooE0cabTdB0T1k0L89lkd+LaWm586orku2t3qo8h35iq?= =?us-ascii?Q?97ENlpwtbTPVwzvPYeHdyaKY/i5ddFwl74XwyO+pO3vWPe7HaVOVScgdyPmC?= =?us-ascii?Q?RvAWMM3hf2jQLO6ClyHZMmXhapN+7N8ATtMxdKSaAKgQB6gb6/79U6vsFie/?= =?us-ascii?Q?HQ=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: a5ad409d-caa9-47d8-98f9-08db70e4ac4b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2023 16:46:04.8231 (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: pj/RKB4+gD91SwHsoBeQOcjndJ+IgjUDVBQzU+DWvdLk/xQ8LbMdXSCAOA8qXsDO+CSPmFfuBfJJRYMb1gHXqE/7W3QN4Uoi7Jw0WETDFs0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR11MB8022 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-11.9 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: > > > The recent commit 421490af33bf ("gdbserver/linux: Access memory even > > > if threads are running") caused a regression in > > > gdb.threads/access-mem-running-thread-exit.exp with gdbserver, which I > > > somehow missed. Like so: > > > > > > (gdb) print global_var > > > Cannot access memory at address 0x555555558010 > > > (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop= : access mem (print > > global_var after writing, inf=3D2, iter=3D1) > > > > > > The problem starts with GDB telling GDBserver to select a thread, via > > > the Hg packet, which GDBserver complies with, then that thread exits, > > > and GDB, without knowing the thread is gone, tries to write to memory, > > > through the context of the previously selected Hg thread. > > > > > > GDBserver's GDB-facing memory access routines, gdb_read_memory and > > > gdb_write_memory, call set_desired_thread to make GDBserver re-select > > > the thread that GDB has selected with the Hg packet. Since the thread > > > is gone, set_desired_thread returns false, and the memory access > > > fails. > > > > > > Now, to access memory, it doesn't really matter which thread is > > > selected. All we should need is the target process. Even if the > > > thread that GDB previously selected is gone, and GDB does not yet know > > > about that exit, it shouldn't matter, GDBserver should still know > > > which process that thread belonged to. > > > > > > Fix this by making GDBserver track the current process separately, > > > like GDB also does. Add a new set_desired_process routine that is > > > similar to set_desired_thread, but just sets the current process, > > > leaving the current thread as NULL. Use it in the GDB-facing memory > > > read and write routines, to avoid failing if the selected thread is > > > gone, but the process is still around. > > > > > > Change-Id: I4ff97cb6f42558efbed224b30d5c71f6112d44cd > > > --- > > > gdbserver/gdbthread.h | 1 + > > > gdbserver/inferiors.cc | 26 +++++++++++++++++++------ > > > gdbserver/server.cc | 4 ++-- > > > gdbserver/target.cc | 44 ++++++++++++++++++++++++++++++++++++++++= -- > > > gdbserver/target.h | 15 +++++++++++++- > > > 5 files changed, 79 insertions(+), 11 deletions(-) > > > > > > diff --git a/gdbserver/gdbthread.h b/gdbserver/gdbthread.h > > > index 10ae1cb7c87..8b897e73d33 100644 > > > --- a/gdbserver/gdbthread.h > > > +++ b/gdbserver/gdbthread.h > > > @@ -252,6 +252,7 @@ class scoped_restore_current_thread > > > > > > private: > > > bool m_dont_restore =3D false; > > > + process_info *m_process; > > > thread_info *m_thread; > > > }; > > > > > > diff --git a/gdbserver/inferiors.cc b/gdbserver/inferiors.cc > > > index 678d93c77a1..3d0a8b0e716 100644 > > > --- a/gdbserver/inferiors.cc > > > +++ b/gdbserver/inferiors.cc > > > @@ -26,6 +26,11 @@ > > > std::list all_processes; > > > std::list all_threads; > > > > > > +/* The current process. */ > > > +static process_info *current_process_; > > > + > > > +/* The current thread. This is either a thread of CURRENT_PROCESS, = or > > > + NULL. */ > > > struct thread_info *current_thread; > > > > > > /* The current working directory used to start the inferior. > > > @@ -130,6 +135,7 @@ clear_inferiors (void) > > > clear_dlls (); > > > > > > switch_to_thread (nullptr); > > > + current_process_ =3D nullptr; > > > } > > > > > > struct process_info * > > > @@ -153,6 +159,8 @@ remove_process (struct process_info *process) > > > free_all_breakpoints (process); > > > gdb_assert (find_thread_process (process) =3D=3D NULL); > > > all_processes.remove (process); > > > + if (current_process () =3D=3D process) > > > + switch_to_process (nullptr); > > > delete process; > > > } > > > > > > @@ -205,8 +213,7 @@ get_thread_process (const struct thread_info *thr= ead) > > > struct process_info * > > > current_process (void) > > > { > > > - gdb_assert (current_thread !=3D NULL); > > > - return get_thread_process (current_thread); > > > + return current_process_; > > > > A bit late I know, but I wonder if the assert, or something similar, > > should have been retained here? > > > > The comment on this function currently (though Baris has a patch > > proposed to change this), says this function should only be called in a > > context where the result will not be nullptr. Given that, not of the > > (many) existing uses check the return value of this function against > > nullptr. > > > > Happy to roll a patch to add the assert back, just wondered if there was > > a reason for its removal. > > > > Thanks, > > Andrew > = > Hi Andrew, > = > I think the current process can in fact be null in some brief periods. > For instance, in 'handle_detach' there is > = > if (extended_protocol || target_running ()) > { > /* There is still at least one inferior remaining or > we are in extended mode, so don't terminate gdbserver, > and instead treat this like a normal program exit. */ > cs.last_status.set_exited (0); > cs.last_ptid =3D ptid_t (pid); > = > switch_to_thread (nullptr); > } > = > So, if the current process exits, gdbserver reports the event to GDB and > sets the current thread to nullptr, which also sets the current process > to nullptr. > = > I believe an invariant is this: > = > (current_thread =3D=3D nullptr) || (current_process () =3D=3D get_threa= d_process (current_thread)) Kindly pinging for/in the context of https://sourceware.org/pipermail/gdb-patches/2023-April/199116.html -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