From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id fwIgDZ3S/Gn9sR8AWB0awg (envelope-from ) for ; Thu, 07 May 2026 13:57:49 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=amd.com header.i=@amd.com header.a=rsa-sha256 header.s=selector1 header.b=svvbselS; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 215121E067; Thu, 07 May 2026 13:57:49 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (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 8ED921E067 for ; Thu, 07 May 2026 13:57:47 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0D3944BA23C3 for ; Thu, 7 May 2026 17:57:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0D3944BA23C3 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=amd.com header.i=@amd.com header.a=rsa-sha256 header.s=selector1 header.b=svvbselS Received: from CO1PR03CU002.outbound.protection.outlook.com (mail-westus2azon11010036.outbound.protection.outlook.com [52.101.46.36]) by sourceware.org (Postfix) with ESMTPS id 330D44BA23C2 for ; Thu, 7 May 2026 17:57:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 330D44BA23C2 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=amd.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 330D44BA23C2 Authentication-Results: sourceware.org; arc=pass smtp.remote-ip=52.101.46.36 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1778176637; cv=pass; b=le89dxi1MscTC+8Kk1TECSywaseXO4wlJEKf3jT7KDYtAX8LPUlJJ6a+vAK25cXH99P9DePoKrtCTpUc5+Uxd4/aVAHjNqyzgeSG1+x/f7Mesjqch4vJT88BhnwVCccL2dcUMy1c8jRifHCLXZzW0gu91Mr8Ruqd1pUqeqls6/o= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1778176637; c=relaxed/simple; bh=OEmw5IUtg7zp4XH6TOMAWqir2ylCeyvcH1/nneHSCeQ=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=R60idjSmiFY77aBlg3AXdI+PjdL/ETikHIT1cE2aEZpCSEQ/anD57ariHJEm6/kU+GOWFpPp5n7LNq9xc8H3gcdbl2IbJij4tWzis89QJllQT8BlyCv6qO6pSqMpq36KblGedEz6cHKlIvrZk5QW62VB81QY3JJNWfCq5kMTv+8= ARC-Authentication-Results: i=2; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=amd.com header.i=@amd.com header.a=rsa-sha256 header.s=selector1 header.b=svvbselS DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 330D44BA23C2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=S3ZoDvjxceIn//TXWRWxXy8WrHslV7Frz64wN3/fHMVBUEpgAxceqCwVOX0TkczJ0vb0L320znhqG5OldiCmnm0L89oTSk7fi8snFAlyS5oxSGQRvWCnWdb8sbPo2QE4PO/jesXS0CgTGs2dLWkZCecFClXw+QnoCRw89uHlEx7UqTwqYvqyUnm/wGRvlm58ywhm1qKLBnFb0zvJJn0+kDM7Yl/3NdIn+e3cDIqcIBceC4c7sWrKKLCyg16/SjrKjrjykqpIrwiO0PnqkYn/OXyautlvhNwM4Rzcif+D+xsE/mHiG1FGiKNPPZJqqafkOfv6ou4sqzh949ixV88ZdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=/2NDNe7REgytQUhLednveHYjfWiCS+gDsP8gbVCRhaA=; b=F2lypE2atyRpiSlI/X97uV1Fstg5KRp1BF/jtgnqwo6TDVy7Gjn/Fy8YKamfvu0IFNzYhBdjVQPtBLxWASaYVK8K2HJSNaG0PeoInqjNNp2fBQ7EmDKbUIw0p1OsLeLkoSKs5wpP4CZuUvwYMqQ8kts+sMTU8R8PrlqdTSzPGJKks9QMnhhYpCRUIeSCCqP8o6KGfXQ53l9KWMWk3h10paJCMYTUVZy3IfJp7vQ4Ome7bH9acm3JXDWWO145CyyVDaAC93MFA9FeL5OKrK1SzB2YV3nQOcBV//GVEB6pZWJvddyr+FJ8wOak4U1TeHnX0xTu4KMZFmKXdFlRlUGI9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=efficios.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/2NDNe7REgytQUhLednveHYjfWiCS+gDsP8gbVCRhaA=; b=svvbselSQjAJEqbN4X18Ah6ZTVTJX9KgZnNm2zIbIAU/0k25xn4C7dph5yXdQ0jRQaaEh+iZa6wDTds0CJNaBu7RFCcsgl/o3l7b2b3vpsz63gw+MeW2c/WungqRSBUcgIMVBzceXFjMCLemiuLfwSbFl8kHVRKPSNmh33ngAxE= Received: from PH8P221CA0060.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:349::9) by MW6PR12MB8758.namprd12.prod.outlook.com (2603:10b6:303:23d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9891.18; Thu, 7 May 2026 17:57:05 +0000 Received: from CY4PEPF0000EE31.namprd05.prod.outlook.com (2603:10b6:510:349:cafe::28) by PH8P221CA0060.outlook.office365.com (2603:10b6:510:349::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9891.18 via Frontend Transport; Thu, 7 May 2026 17:57:05 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE31.mail.protection.outlook.com (10.167.242.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9891.9 via Frontend Transport; Thu, 7 May 2026 17:57:04 +0000 Received: from khazad-dum (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 7 May 2026 12:57:03 -0500 Date: Thu, 7 May 2026 18:56:53 +0100 From: Lancelot SIX To: Simon Marchi CC: Subject: Re: [PATCH 1/11] gdb/solib-rocm: assert that host ops isn't rocm_solib_ops Message-ID: References: <20251209193610.296085-2-simon.marchi@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251209193610.296085-2-simon.marchi@efficios.com> X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE31:EE_|MW6PR12MB8758:EE_ X-MS-Office365-Filtering-Correlation-Id: 574633cb-747a-4ab6-5e40-08deac620c72 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|1800799024|36860700016|376014|82310400026|56012099003|18002099003|22082099003|3023799003; X-Microsoft-Antispam-Message-Info: ++mOX22tQ3zEgkyUYK2flsV89LLRx2yC6SCZt5MlslEkdhHx1zdwuAhZ41XT+tw22PgQq4NdxjwT4b44VONQcRAikRzIbbH7cTBpF1aA1K7wD+tx9l3TBqpIgqAfyI624UD9HHTouSpjPbkjkQaLlV1jnd6aYfCxBnpJKDhl+ekpa5937ZuxV2qzDl4hH3QIECbtHqZD+L/N5wxbWp/yzSDGQ1I3YwoxvpeLEf3MZ3jl+zj8HCdwC2t2yMnHl5lq2eMHyDqp6t/RLGCDykmQMBsQabkD4s131GJ2ASWP7KyVby7RXWdt1U8h1CeaR/yFoiBtgC1UDNW1UdxhBlWg+DoB0+kP5JfnWKfIQTYca/pR79yRqIQUQxRq84AbvOZbVQCLTxnCvhuQxiZ1TH4cPDdQkE/A04tlaWOmPO8uonbJSXAAY2IhMvGpHJSkTmx18BdBI2zjgBO4EmIuXwq47al0oZ31xfN0JwODM3one4LskCy5YbvzKVky+Z3t6DdhTLyd9xm9P+5ialS0nRcCBFmx3opQt67UPiyjiPhrjIHykDFctQprbcD5+gUecVDmpZLVZmLb6PkQMB1JD3O6t7T4EE/oI+lqtGlIG1LM4eeoA4hihmTHVaDqMXBrv3MqWATNgiMAUwJ9a1oW5JzrGS0mpuG7ke4qq+UgKjl+CGLXOWH8Bcc9qR4k+EC76YtNCY79dvYchQKBFBL65tKC3Z2l1G5LN6B8IjlFsN0qzwA= X-Forefront-Antispam-Report: CIP:165.204.84.17; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:satlexmb07.amd.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230040)(1800799024)(36860700016)(376014)(82310400026)(56012099003)(18002099003)(22082099003)(3023799003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: zp5Wz4LlTgYd6PfqqbLEDO4BivDa3Tbiypn8Qt9gXhLJnTqJuK5ojNvU4cVYHs72mlUGNCZBuG0lKTYjSvr7V0sbmjOpwFTVLQ/C2wFVD6eIdMuzWYKpOrx2DjgwTeQzNtTISKz1l9CP5rJQVEGBXKBQefRqWc/3HyXg565CcpdnxW8ibo+GuYqPWL3p3OVdZvhzRtNWS5akvBMNc0biPckvLEYhZATj2vvwNDjJT+itasBm55md2aI3DbyqCJadfSd5wHROOUYFo8bkieWEV86R1tSlD8Uwr5nvp6QEB90B+crU7OHz0IUGeXPs3Rox61kktWTUQYH7s8ubbHJBAJAU78dwb4VILpYDgQtpTLTfmMcQICFqkBVyBd6SB1ce5P8RijVrMsBKR5Q41rmKSwehNZtG6r8PAlCOhSUdU7SiYmM/iaYlftgMABy/U2wx X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2026 17:57:04.8318 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 574633cb-747a-4ab6-5e40-08deac620c72 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d; Ip=[165.204.84.17]; Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000EE31.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8758 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 Hi Simon, Please accept my appologies for the delay to get to this series. On Tue, Dec 09, 2025 at 02:32:05PM -0500, Simon Marchi wrote: > In some fork cases, the rocm_solib_target_inferior_created observer gets > called while the child inferior (passed as a parameter) already has a > rocm_solib_ops installed. Since we unconditionally wrap the existing > solib_ops with a new rocm_solib_ops, we can end up with a chain of > multiple rocm_solib_ops, like: > > rocm_solib_ops -> rocm_solib_ops -> svr4_solib_ops > > I don't think it is technically harmful as of now (unless the process > does a ton of forks and the rocm_solib_ops accumulate), but it is for > sure useless. Add an assert for this in the rocm_solib_ops constructor, > which reveals the cases where this happens. > > When a fork happens with follow-fork-mode == child and detach-on-fork > on, infrun's follow_fork_inferior function directly moves the program > space from the parent the child inferior, as an optimization. Coming > into rocm_solib_target_inferior_created, the inferior's pspace > unexpectedly already has a rocm_solib_ops pushed. > > Fix this locally by using an inferior_forked observer. In the scenario > described above, remove the rocm_solib_ops and restore the host > solib_ops as the program space's solib_ops, to make it look as if infrun > didn't do this trick. This requires adding two parameters to the > inferior_forked observer (detach_on_fork and follow_child). > > This should probably be done by infrun directly at some point. The > logic being that it's fine to do an optimization, but it should look as > if it didn't occur. If infrun created a brand new pspace for the child, > there wouldn't be a rocm_solib_ops there already. But I prefer a local > fix for now. > > Finally, there are also the vfork cases, where the child inferior shares > the program space with its parent, and therefore the child's program > space already has a rocm_solib_ops installed. Address this case by > returning early (the `inf->vfork_parent != nullptr` check), because > there is nothing we want to do for a vfork child anyway. > > Change-Id: I2e76d111e96f1e01b6799b04da9cdd6f6e2984c9 > --- > gdb/amd-dbgapi-target.c | 3 ++- > gdb/infrun.c | 3 ++- > gdb/observable.h | 8 ++++++-- > gdb/solib-rocm.c | 31 +++++++++++++++++++++++++++++++ > 4 files changed, 41 insertions(+), 4 deletions(-) > > diff --git a/gdb/amd-dbgapi-target.c b/gdb/amd-dbgapi-target.c > index d296f2830063..87b834739e2d 100644 > --- a/gdb/amd-dbgapi-target.c > +++ b/gdb/amd-dbgapi-target.c > @@ -2102,7 +2102,8 @@ amd_dbgapi_inferior_execd (inferior *exec_inf, inferior *follow_inf) > > static void > amd_dbgapi_inferior_forked (inferior *parent_inf, inferior *child_inf, > - target_waitkind fork_kind) > + target_waitkind fork_kind, bool detach_on_fork, > + bool follow_child) > { > if (child_inf != nullptr) > { > diff --git a/gdb/infrun.c b/gdb/infrun.c > index bd114e16b80e..e0ffe95e4e45 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -645,7 +645,8 @@ holding the child stopped. Try \"set %ps\" or \"%ps\".\n"), > target_follow_fork (child_inf, child_ptid, fork_kind, follow_child, > detach_fork); > > - gdb::observers::inferior_forked.notify (parent_inf, child_inf, fork_kind); > + gdb::observers::inferior_forked.notify (parent_inf, child_inf, fork_kind, > + detach_fork, follow_child); > > /* target_follow_fork must leave the parent as the current inferior. If we > want to follow the child, we make it the current one below. */ > diff --git a/gdb/observable.h b/gdb/observable.h > index 5f064cf1fc8c..c8cbdbad97d1 100644 > --- a/gdb/observable.h > +++ b/gdb/observable.h > @@ -92,9 +92,13 @@ extern observable > the child (because we follow only the child or we follow both), CHILD_INF > is the child inferior. Otherwise, CHILD_INF is nullptr. > > - FORK_KIND is TARGET_WAITKIND_FORKED or TARGET_WAITKIND_VFORKED. */ > + FORK_KIND is TARGET_WAITKIND_FORKED or TARGET_WAITKIND_VFORKED. > + > + detach_on_fork and follow_child represent the "detach-on-fork" and > + "follow-fork-mode" settings. */ Just a nitpick here. Should DETACH_ON_FORK and FOLLOW_CHILD be upper case? > extern observable - target_waitkind /* fork_kind */> inferior_forked; > + target_waitkind /* fork_kind */, bool /* detach_on_fork */, > + bool /* follow_child */> inferior_forked; > > /* The shared library specified by SOLIB has been loaded. Note that > when gdb calls this observer, the library's symbols probably > diff --git a/gdb/solib-rocm.c b/gdb/solib-rocm.c > index d97ab25df5d0..a9573f8eefde 100644 > --- a/gdb/solib-rocm.c > +++ b/gdb/solib-rocm.c > @@ -164,8 +164,14 @@ struct rocm_solib_ops : public solib_ops > explicit rocm_solib_ops (program_space *pspace, solib_ops_up host_ops) > : solib_ops (pspace), m_host_ops (std::move (host_ops)) > { > + gdb_assert (m_host_ops != nullptr); > + gdb_assert (dynamic_cast (m_host_ops.get ()) == nullptr); > } > > + /* Release the host solib_ops. */ > + solib_ops_up release_host_ops () > + { return std::move (m_host_ops); } > + > /* The methods implemented by rocm_solib_ops. */ > owning_intrusive_list current_sos () const override; > void create_inferior_hook (int from_tty) const override; > @@ -808,6 +814,10 @@ rocm_update_solib_list () > static void > rocm_solib_target_inferior_created (inferior *inf) > { > + /* A vfork child shares its pspace with its parent, do not touch anything. */ > + if (inf->vfork_parent != nullptr) > + return; > + > get_solib_info (inf)->solib_list.clear (); > > auto prev_ops = inf->pspace->release_solib_ops (); > @@ -839,6 +849,24 @@ rocm_solib_target_inferior_execd (inferior *exec_inf, inferior *follow_inf) > get_solib_info (exec_inf)->solib_list.clear (); > } > > +static void > +rocm_solib_target_inferior_forked (inferior *parent_inf, inferior *child_inf, > + target_waitkind fork_kind, > + bool detach_on_fork, bool follow_child) > +{ > + if (detach_on_fork && follow_child && fork_kind == TARGET_WAITKIND_FORKED) > + { > + /* In this particular configuration, infrun's follow_fork_inferior > + function moves the parent pspace to the child directly. Remove the > + existing rocm_solib_ops from the child and restore the host solib_ops, > + to make it look like a brand new pspace. */ > + auto rocm_ops_holder = child_inf->pspace->release_solib_ops (); > + auto rocm_ops > + = gdb::checked_static_cast (rocm_ops_holder.get ()); > + child_inf->pspace->set_solib_ops (rocm_ops->release_host_ops ()); I think I am overall OK with the approach, even if I would prefer not have the target explicitly rely on assumption about what the core does. If the core in infrun was to change at some point, I expect this would fail: the pspace's solib would not be a rocm_solib_ops, so checked_static_cast would fail. Should this use dynimac_cast and test for nullptr instead? Would it work to do it unconditionnaly (not check for detach_on_fork and follow_inf), check if the pspace's solib is the rocm one, and if so use the host one instead? And last question, shouldn't this be in solib-rocm.c rather than amd-dbgapi-target.c? Best, Lancelot. > + } > +} > + > INIT_GDB_FILE (rocm_solib) > { > /* The dependency on the amd-dbgapi exists because solib-rocm's > @@ -852,4 +880,7 @@ INIT_GDB_FILE (rocm_solib) > gdb::observers::inferior_execd.attach > (rocm_solib_target_inferior_execd, "solib-rocm", > { &get_amd_dbgapi_target_inferior_execd_observer_token () }); > + > + gdb::observers::inferior_forked.attach > + (rocm_solib_target_inferior_forked, "solib-rocm"); > } > -- > 2.52.0