[v6,14/17,gdb/generic] corefile/bug: Use thread-specific gdbarch when dumping register state to core files
Message ID | 20230913101815.178154-15-luis.machado@arm.com |
---|---|
State | New |
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> 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 1E05E3853D33 for <patchwork@sourceware.org>; Wed, 13 Sep 2023 10:20:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1E05E3853D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1694600455; bh=IJROVNSxyrLd9HQizNQqvnHlKDktgL0eu9Ub/0kJ84E=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=m92L9gcP7QuJgvCVJssZoP3sC5T9EwJes8DR5FGpLUK8ofGopt/ge1Muead5Fb06g H7SVsga3Br36zcV1WTTYG5GpaNZzxrVSKE4f1LvYqx7uAR+/J9x5rNfzmSAOX9bcRk N62dP/TkwWLsD3MxpPPyeGVw9GQsSrpsmeDkrWZs= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on2059.outbound.protection.outlook.com [40.107.8.59]) by sourceware.org (Postfix) with ESMTPS id CE99B3853D16 for <gdb-patches@sourceware.org>; Wed, 13 Sep 2023 10:18:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CE99B3853D16 Received: from DU6P191CA0049.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:53e::8) by AM8PR08MB6385.eurprd08.prod.outlook.com (2603:10a6:20b:36a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6768.37; Wed, 13 Sep 2023 10:18:46 +0000 Received: from DBAEUR03FT019.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:53e:cafe::f7) by DU6P191CA0049.outlook.office365.com (2603:10a6:10:53e::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.19 via Frontend Transport; Wed, 13 Sep 2023 10:18:46 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DBAEUR03FT019.mail.protection.outlook.com (100.127.142.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.19 via Frontend Transport; Wed, 13 Sep 2023 10:18:45 +0000 Received: ("Tessian outbound b5a0f4347031:v175"); Wed, 13 Sep 2023 10:18:45 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 4356352028e480fa X-CR-MTA-TID: 64aa7808 Received: from 07fc22b8eaef.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id AC5B7629-0DFC-4EA4-BD9F-288CF9034CBE.1; Wed, 13 Sep 2023 10:18:38 +0000 Received: from EUR03-AM7-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 07fc22b8eaef.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 13 Sep 2023 10:18:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KYA/SrleI8HocUWw2obxWO+sINFD3ZI8XjhX9unJ22Pj1qlq1jd48WRuODoe8z/7cB4vo/yzoQa8W0Y7/muh78/d6TiFfpFZzIkV6rrht/7WLjwlpNalm1q9PACrmSTv+mvgxiWUDxIaAur6uTsW8X3TneB03a6S5d7UbV8tRVQi0PzW7dlpvf1wsMmFtQ1GxZQ5M7Bx7ZD9bNxczsiTS52beXPtU0xpwJpj66ieqKTOlLc0+OOjow2ni5vmYqiAqcWZVy3nZWCEYZAEFMhQa7KZCH17HnUTEPWTtIdSBm2rW9jF9BcExRVMgp1+jUfDOAZfPiLOziBoAsFtcvon+g== 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=IJROVNSxyrLd9HQizNQqvnHlKDktgL0eu9Ub/0kJ84E=; b=kUFr6LCabh4dIYYyXU9YVBSPTZotzg1u35aEREVqv3MH2s87qTNxDNZnuDjPd/9fjbwLHybZIkAuWi14hZZuZQTyyRCShyDfboJ2RFndbxpkgKnj4R0VlylcSsEeVBVHykFuwUrNBKCxZW+IgUMuyjTG8INnowx+1a/ewF0GP5+kG5IttI+e3QmbuWMq4PPxsvIl5VDuvvaY2IO3maxkoNkscSeL470KmFtD2mfJ5aQRqBwkXTukPbtjxL1NFU2CcAAjzzlcnDKEuofQ2MSA+1NbxoMYLZpO5aoozofLYAWDXv99jWJofDKWfMGdLc/bSJvki5psmglZ6HSVrYtcXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 40.67.248.234) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=none (message not signed); arc=none Received: from AM6PR10CA0093.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:8c::34) by GVXPR08MB7679.eurprd08.prod.outlook.com (2603:10a6:150:6f::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6768.30; Wed, 13 Sep 2023 10:18:36 +0000 Received: from AM7EUR03FT034.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8c:cafe::8) by AM6PR10CA0093.outlook.office365.com (2603:10a6:209:8c::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.19 via Frontend Transport; Wed, 13 Sep 2023 10:18:36 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 40.67.248.234) smtp.mailfrom=arm.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 40.67.248.234 as permitted sender) receiver=protection.outlook.com; client-ip=40.67.248.234; helo=nebula.arm.com; pr=C Received: from nebula.arm.com (40.67.248.234) by AM7EUR03FT034.mail.protection.outlook.com (100.127.140.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6792.20 via Frontend Transport; Wed, 13 Sep 2023 10:18:36 +0000 Received: from AZ-NEU-EX02.Emea.Arm.com (10.251.26.5) by AZ-NEU-EX03.Arm.com (10.251.24.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Wed, 13 Sep 2023 10:18:31 +0000 Received: from AZ-NEU-EX04.Arm.com (10.251.24.32) by AZ-NEU-EX02.Emea.Arm.com (10.251.26.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Wed, 13 Sep 2023 10:18:31 +0000 Received: from e129171.arm.com (10.57.66.200) by mail.arm.com (10.251.24.32) with Microsoft SMTP Server id 15.1.2507.27 via Frontend Transport; Wed, 13 Sep 2023 10:18:31 +0000 To: <gdb-patches@sourceware.org> Subject: [PATCH v6 14/17] [gdb/generic] corefile/bug: Use thread-specific gdbarch when dumping register state to core files Date: Wed, 13 Sep 2023 11:18:12 +0100 Message-ID: <20230913101815.178154-15-luis.machado@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230913101815.178154-1-luis.machado@arm.com> References: <20230913101815.178154-1-luis.machado@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 1 X-MS-TrafficTypeDiagnostic: AM7EUR03FT034:EE_|GVXPR08MB7679:EE_|DBAEUR03FT019:EE_|AM8PR08MB6385:EE_ X-MS-Office365-Filtering-Correlation-Id: a6ba1ba1-25ee-4fc8-e50c-08dbb442d063 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: yTqxIgqSrkazbbIWvVopCQ2ZOLjkSwQEayyPMD60OkNkramEooqerylx/Sq8Bh5BkJpfFIoL6WUllzUfO/RT1wU6bBpovd9TdgrOJdyFlJ9FR/fcvrVdwd6rCl6opyGCu/PdjbI8MpXIlSBv/4kYT7A6I7sv+hNDcC0OcVj1zODk4rxgcgRh3oJrIV+NOrrRy41TepQEIWgRiZAn3bSWxMIkFAeAOXtBMGuFESKrF6ukeFamNnh1oFAH8XymEYlLF3meBw9aS9PhpahTQ411FA8Nz+yytMDm+xgSJ/oNAHv07Z24y+1xEl2u+7nUHZyJAWqrKpqKd6pwxojYHtDnur06yROshGWdaXM4UPS7MPR03K+4fxPOR9UA0jnOyqCn8rS1Albo3zaj8ClZGlzX2iEe5et2miMeGotzA2d09RJN9OtfwAX/fibiggBoWFB5cyodTGWD4kRPyhKsDZI5LueeyMqKXKkGtVJ6C1vx8zJOY9VN0CQ3sKCM3WUgIvnS6fysJLYZKquq7Ql/Zk/hfJRcNLj1IkfF01bEhW0bpvTKUekKRb4DsWOjVFVq3JGWe062c7j0SxAvkE2gtcKa7JSE4v7OHeKe4OqLKHCupbNbxNgYkHOpHBDK23bMIow5wI6mC2EIuGOt3pr/XCzw4YZ3T5j5tFne3cM9ZAdn6sLFRA3kxa7mMW2vWbFQBA2HBiHL+RvTqUlu+Jw/P+IRSjzAZ6mc9Un0BF329KzhNgZ5/hd/u0iFd2Ly4QeCXEhKZBQD/AByHB1qRQi0gYI1ayP8l4R1qaNbZ0zS50TgLQA= X-Forefront-Antispam-Report-Untrusted: CIP:40.67.248.234; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:nebula.arm.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230031)(4636009)(396003)(376002)(346002)(136003)(39860400002)(1800799009)(186009)(451199024)(82310400011)(36840700001)(40470700004)(46966006)(5660300002)(70206006)(356005)(81166007)(7696005)(6666004)(2906002)(47076005)(36756003)(86362001)(82740400003)(40480700001)(336012)(2616005)(36860700001)(1076003)(426003)(26005)(478600001)(70586007)(83380400001)(44832011)(40460700003)(4326008)(8676002)(8936002)(41300700001)(6916009)(54906003)(316002)(41533002)(36900700001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB7679 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DBAEUR03FT019.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 4f437888-3216-452d-0dbe-08dbb442cab2 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1SHBKBjdxm1dH2yhdehWOKoSiFP+z1HbNz5SiOU+MkBdUOEUWNcN+ugwkTOqjh53TBDwKjaRYx36kousdB/LsgwmMPXhXHZ6H4vdXJCCSZsCrtu1vUsdbM/ofUVYbD3qn+j3iJNmbJp7zm/xmtDPqZ+pjroat27Dp3hVW+4wjlfVQtufiDOACeE5TcyQK7dsXqg9i+UQroafFljLxokalqosSrBHHfXs/teXiqcATwaE3dCP4D0HaFOzy3BBQFf1vPRY5D2PfRcrfmwarlAACNyMbZrB/6zz7dWByJn6pCDE1ZSoBOvEDciHuyS2JaKOsxLk8C6ij2x+Y2Uhk+rNIVDIHW+WrKO8hw9+sOy7bPnn2nWdTSRj1Yc2TbyeV6a8/q5vK5u7Xx4wJvN3qVKx6wTB6JzaxHjm4r/Y90fxNd4VprYREoPsIi49kE//3MUtdbBSY4TXZ2QfeTq9hwP094cusuEUmR6sdrEZ8SGqCzLNflMxhnY18hGhW2wn9o3GUCZHuLoNoLgilS7L7/sidBoRaeQHf0gQqSYQeqkEA8SVXkafPwNvYsLvX6Gyi4PsGDaZjENuYJti9KV0kXKg3OApXOQJWGShlunUaHBw+Zqi9QtOwsYqvvXrTHI2tWiIuTCkAEOkPNrlL8teoxBbzSOUkaUE/lwj5FqBsNNVWAKCCPOix99Icr2gVgB7nFXIjrmmPDUkRSBJ272NGqLeRDfOAuQZ+0FTvQn++xBfVRAOJ/N4L5dDjqRMFcVPLoE32AvCfLJ0UPD6cF8TSxjcTg== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230031)(4636009)(39860400002)(376002)(346002)(396003)(136003)(451199024)(82310400011)(186009)(1800799009)(46966006)(40470700004)(36840700001)(86362001)(40480700001)(5660300002)(44832011)(8676002)(8936002)(40460700003)(2906002)(4326008)(36756003)(26005)(7696005)(82740400003)(6666004)(1076003)(478600001)(107886003)(336012)(2616005)(81166007)(426003)(47076005)(36860700001)(41300700001)(83380400001)(70206006)(70586007)(6916009)(316002)(54906003)(41533002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2023 10:18:45.9949 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a6ba1ba1-25ee-4fc8-e50c-08dbb442d063 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DBAEUR03FT019.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB6385 X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, UNPARSEABLE_RELAY 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.30 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> From: Luis Machado via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Luis Machado <luis.machado@arm.com> Cc: thiago.bauermann@linaro.org Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
SME support for AArch64 gdb/gdbserver on Linux
|
|
Checks
Context | Check | Description |
---|---|---|
linaro-tcwg-bot/tcwg_gdb_build--master-arm | success | Testing passed |
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 | success | Testing passed |
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 | success | Testing passed |
linaro-tcwg-bot/tcwg_gdb_check--master-arm | success | Testing passed |
Commit Message
Luis Machado
Sept. 13, 2023, 10:18 a.m. UTC
When we have a core file generated by gdb (via the gcore command), gdb dumps the target description to a note. During loading of that core file, gdb will first try to load that saved target description. This works fine for almost all architectures. But AArch64 has a few dynamically-generated target descriptions/gdbarch depending on the vector length that was in use at the time the core file was generated. The target description gdb dumps to the core file note is the one generated at the time of attachment/startup. If, for example, the SVE vector length changed during execution, this would not reflect on the core file, as gdb would still dump the initial target description. Another issue is that the gdbarch potentially doesn't match the thread's real gdbarch, and so things like the register cache may have different formats and sizes. To address this, fetch the thread's architecture before dumping its register state. That way we will always use the correct target description/gdbarch. --- gdb/linux-tdep.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)
Comments
On 9/13/23 06:18, Luis Machado wrote: > When we have a core file generated by gdb (via the gcore command), gdb dumps > the target description to a note. During loading of that core file, gdb will > first try to load that saved target description. > > This works fine for almost all architectures. But AArch64 has a few > dynamically-generated target descriptions/gdbarch depending on the vector > length that was in use at the time the core file was generated. > > The target description gdb dumps to the core file note is the one generated > at the time of attachment/startup. If, for example, the SVE vector length > changed during execution, this would not reflect on the core file, as gdb > would still dump the initial target description. > > Another issue is that the gdbarch potentially doesn't match the thread's > real gdbarch, and so things like the register cache may have different formats > and sizes. > > To address this, fetch the thread's architecture before dumping its register > state. That way we will always use the correct target description/gdbarch. > --- > gdb/linux-tdep.c | 23 +++++++++++++++++++---- > 1 file changed, 19 insertions(+), 4 deletions(-) > > diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c > index a4a86b01bdb..2885afd60c7 100644 > --- a/gdb/linux-tdep.c > +++ b/gdb/linux-tdep.c > @@ -2078,15 +2078,30 @@ linux_make_corefile_notes (struct gdbarch *gdbarch, bfd *obfd, int *note_size) > stop_signal = GDB_SIGNAL_0; > > if (signalled_thr != nullptr) > - linux_corefile_thread (signalled_thr, gdbarch, obfd, note_data, note_size, > - stop_signal); > + { > + /* On some architectures, like AArch64, each thread can have a distinct > + gdbarch (due to scalable extensions), and using the inferior gdbarch > + is incorrect. > + > + Fetch each thread's gdbarch and pass it down to the lower layers so > + we can dump the right set of registers. */ > + linux_corefile_thread (signalled_thr, > + target_thread_architecture (signalled_thr->ptid), > + obfd, note_data, note_size, stop_signal); > + } > for (thread_info *thr : current_inferior ()->non_exited_threads ()) > { > if (thr == signalled_thr) > continue; > > - linux_corefile_thread (thr, gdbarch, obfd, note_data, note_size, > - stop_signal); > + /* On some architectures, like AArch64, each thread can have a distinct > + gdbarch (due to scalable extensions), and using the inferior gdbarch > + is incorrect. > + > + Fetch each thread's gdbarch and pass it down to the lower layers so > + we can dump the right set of registers. */ > + linux_corefile_thread (thr, target_thread_architecture (thr->ptid), > + obfd, note_data, note_size, stop_signal); > } > > if (!note_data) > -- > 2.25.1 > Approved-By: Simon Marchi <simon.marchi@efficios.com> Simon
>>>>> "Luis" == Luis Machado via Gdb-patches <gdb-patches@sourceware.org> writes:
Luis> When we have a core file generated by gdb (via the gcore command), gdb dumps
Luis> the target description to a note. During loading of that core file, gdb will
Luis> first try to load that saved target description.
Luis> This works fine for almost all architectures. But AArch64 has a few
Luis> dynamically-generated target descriptions/gdbarch depending on the vector
Luis> length that was in use at the time the core file was generated.
Luis> The target description gdb dumps to the core file note is the one generated
Luis> at the time of attachment/startup. If, for example, the SVE vector length
Luis> changed during execution, this would not reflect on the core file, as gdb
Luis> would still dump the initial target description.
Luis> Another issue is that the gdbarch potentially doesn't match the thread's
Luis> real gdbarch, and so things like the register cache may have different formats
Luis> and sizes.
Luis> To address this, fetch the thread's architecture before dumping its register
Luis> state. That way we will always use the correct target description/gdbarch.
FWIW this seems fine to me.
Approved-By: Tom Tromey <tom@tromey.com>
Tom
diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c index a4a86b01bdb..2885afd60c7 100644 --- a/gdb/linux-tdep.c +++ b/gdb/linux-tdep.c @@ -2078,15 +2078,30 @@ linux_make_corefile_notes (struct gdbarch *gdbarch, bfd *obfd, int *note_size) stop_signal = GDB_SIGNAL_0; if (signalled_thr != nullptr) - linux_corefile_thread (signalled_thr, gdbarch, obfd, note_data, note_size, - stop_signal); + { + /* On some architectures, like AArch64, each thread can have a distinct + gdbarch (due to scalable extensions), and using the inferior gdbarch + is incorrect. + + Fetch each thread's gdbarch and pass it down to the lower layers so + we can dump the right set of registers. */ + linux_corefile_thread (signalled_thr, + target_thread_architecture (signalled_thr->ptid), + obfd, note_data, note_size, stop_signal); + } for (thread_info *thr : current_inferior ()->non_exited_threads ()) { if (thr == signalled_thr) continue; - linux_corefile_thread (thr, gdbarch, obfd, note_data, note_size, - stop_signal); + /* On some architectures, like AArch64, each thread can have a distinct + gdbarch (due to scalable extensions), and using the inferior gdbarch + is incorrect. + + Fetch each thread's gdbarch and pass it down to the lower layers so + we can dump the right set of registers. */ + linux_corefile_thread (thr, target_thread_architecture (thr->ptid), + obfd, note_data, note_size, stop_signal); } if (!note_data)