From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on2077.outbound.protection.outlook.com [40.107.8.77]) by sourceware.org (Postfix) with ESMTPS id 540663870C35 for ; Wed, 4 Oct 2023 15:27:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 540663870C35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PBgyB6Z3Sawx+UZqJEyzfMWR6Ne+ePRGDHj0qB2QeW4=; b=Athdqvji27IlLxccJ6OoSwenPymyIjsEJnSHPUbPslaOVskW300nQgxA+cLmDw9EXqsftYr4uASPoDizH+8VxHYEkj0rc2ZFRz9x/8bIrIhm/DhDh+BmK6q038PAJjlv0bWO4/65JMrIeJx/lFd3tFy68FkeaTC6ZKJScVB2hxU= Received: from DB8P191CA0013.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:130::23) by VI1PR08MB5390.eurprd08.prod.outlook.com (2603:10a6:803:13d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.26; Wed, 4 Oct 2023 15:27:49 +0000 Received: from DBAEUR03FT055.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:130:cafe::57) by DB8P191CA0013.outlook.office365.com (2603:10a6:10:130::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.33 via Frontend Transport; Wed, 4 Oct 2023 15:27:49 +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 DBAEUR03FT055.mail.protection.outlook.com (100.127.142.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6863.26 via Frontend Transport; Wed, 4 Oct 2023 15:27:49 +0000 Received: ("Tessian outbound d219f9a4f5c9:v211"); Wed, 04 Oct 2023 15:27:49 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 067db8973dc37221 X-CR-MTA-TID: 64aa7808 Received: from d1409d419b12.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 7C1A3A1C-81BC-4AF8-873D-45295494E542.1; Wed, 04 Oct 2023 15:27:42 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d1409d419b12.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 04 Oct 2023 15:27:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BgIS/epnJA4srB490KhFvNcbHgvoJpuoljgKIqa3tiVPzYCjkygPgQuyrQoGCE45zlmiDvlIu5CewPZHE6z9DoIGMPlMWZtddK7rsuD/+Ru8jPXSWNuJoxbwEkXI3zl+yk0SoZ6pK2x5869vQVk4FsukYrf3Ad/pKuwCIHm35B3xBB8nELdoRdGP5cux+UqGCacekUFnONNiVgRS4JZCv0gXVrHv3Jz4bTjD8LdLpmcnwFFXTZZLBm5UoLjmo7QKRdxrgIhpvijWjq3M/ouIdR6ISsi/ocKHExtqfOc45hfjDOQfM4mfNLOjwWVV89YJFbkifPyOiXbjCrbuRj1Z5Q== 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=PBgyB6Z3Sawx+UZqJEyzfMWR6Ne+ePRGDHj0qB2QeW4=; b=WDaI2e1HhnBexb4KE51P1k9Ym1J3qZJAbpfkj7jTPjLUSz371UAtrlvkFLogIkpjXchxAqVOUMCmCqbGEhnVjGwEbDiDR6D2nXEcofI3omWTQ6hAE2t/APeKlbvdN42q85gErsetckH7Fo0/uXTmOGiHVNGPhODdqIupcodtqJoIjPSvS+qGJCPiDBRqI2siqIykEipGdp55uwO+FGOckhedtVdPkFRjbc+n5Zg16Sm+PdcpQd7P+Fj4h+Sc7AhNKG4QsNJbVQRDUvA2InWdB6ye3aw+K13LGeH6pP4CVOGOUHcNQ360m9U057KDMtFP+KStQjnhzaXkGTHxxwATsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PBgyB6Z3Sawx+UZqJEyzfMWR6Ne+ePRGDHj0qB2QeW4=; b=Athdqvji27IlLxccJ6OoSwenPymyIjsEJnSHPUbPslaOVskW300nQgxA+cLmDw9EXqsftYr4uASPoDizH+8VxHYEkj0rc2ZFRz9x/8bIrIhm/DhDh+BmK6q038PAJjlv0bWO4/65JMrIeJx/lFd3tFy68FkeaTC6ZKJScVB2hxU= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) by DU0PR08MB9275.eurprd08.prod.outlook.com (2603:10a6:10:41b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.35; Wed, 4 Oct 2023 15:27:38 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::ec3b:5cf4:e970:6f67]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::ec3b:5cf4:e970:6f67%7]) with mapi id 15.20.6838.033; Wed, 4 Oct 2023 15:27:36 +0000 Message-ID: <7c43c953-b6df-721c-903f-7dcc342fe7ad@arm.com> Date: Wed, 4 Oct 2023 16:27:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v7 15/18] [gdb/generic] corefile/bug: Add hook to control the use of target description notes from corefiles Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org Cc: thiago.bauermann@linaro.org References: <20230918212651.660141-1-luis.machado@arm.com> <20230918212651.660141-16-luis.machado@arm.com> <87pm2cyldy.fsf@redhat.com> <87led0yif2.fsf@redhat.com> <423fed06-ce80-52d0-013d-03384fecc853@arm.com> <87il83yhbj.fsf@redhat.com> <10c90dbb-75fc-43fa-a3b4-90359ad21f51@arm.com> <87bkdqy3qe.fsf@redhat.com> <87fs2zwlda.fsf@redhat.com> <87y1gjwrgg.fsf@redhat.com> From: Luis Machado In-Reply-To: <87y1gjwrgg.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0437.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a9::10) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|DU0PR08MB9275:EE_|DBAEUR03FT055:EE_|VI1PR08MB5390:EE_ X-MS-Office365-Filtering-Correlation-Id: d6e4ef6a-e838-4884-bc25-08dbc4ee77d4 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: gRw/6SsEWXEUpRZE1wnBANuYcgBK/A5FNb13BYZ8XIOqfa/J14tgwnyR84GgKTzTmA1VdBX/piQbn4svCwyhazKz65qFWdk9p5mofvm1ee8UlpUl2a5vAkCUOEk3Tgnj10xMjLWTmLmI6Jl97ae0OfrHzyW5IhVBsXv4LTz+lX7aAmOfWfZhIOdNPgjzppAEYbl9vlW+Ro6jFc9Wy+SUpwp6YcYdPblynpW04iLXTgq6rJHWvql94Xzxm/5urTJyJxpHTuRrmjj5bMTaUEfGOKLSelx3HamD4mVyrMKuexifzGI5agpFfloL7nyD3GqsH0GUHLE/ngP/tTCaMhnluoa6Wv3ycusRFY5iVv5S8DTV8w7ef6VmBGWtJVARoltU9kU7VTdv2l8gfm68sQnPJdVum+qXzoPgIWsqkcRALHnMgCAMoLAGyVGieEA7EuiaP3zTl9U0zZeaQJCUt0D3QTC2ZJM7j3B5+5LYChh/G+MhOTBBLfB4RfRsbrnwRTDBb2xd8d+S36YrnmN0K9eMUVI4JmZbRZAFKsO//P2jca2vEMHLQZne/UeW6Y4qkxtmWdE67jsh5tIHJe0NtFAYdAmpmu6w7hIM5qPpw7xz03888uWdVzNOq3Jq+soYiAnvLJ9mL5N7tHVVvbny8fw1IVDEydLFMw2CO0QsRZ/c2no= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3919.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366004)(136003)(376002)(396003)(346002)(39860400002)(230922051799003)(451199024)(186009)(64100799003)(1800799009)(2616005)(8936002)(4326008)(8676002)(26005)(86362001)(38100700002)(36756003)(31696002)(2906002)(83380400001)(30864003)(5660300002)(44832011)(6666004)(53546011)(6512007)(6486002)(6506007)(478600001)(31686004)(316002)(66946007)(66556008)(66476007)(41300700001)(41533002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9275 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DBAEUR03FT055.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 7d96da35-d2e5-48a1-05af-08dbc4ee6f7d X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MLUEvt0DerJJDakIOpCiu3XfkjJr5qaDkI3ziwLTJigMnjr9aPOER8sV6hQlDDPQc9K+3jT0jYhtBO4M+UVXX7xt0400cu1jJUbrQGs2MOdxxWi05iJltU5S6I3PTpXF0JP2FYSK8KwIJkp6pDA9XJDSxCrccoEBmZd8Bl/bNE56E3EGmC3F+Xrxxj1NEiZL6sUqdhO27zsX6dzhw2whWlzUl0B7QWgYqUr/hxXjW3hK+wv4HfgTVCoh/woPmX5TJI34s2xsd0aQbff5QSElFQizoXUYEHcwpyUpgjNyuqXuZNPJBkfLhWmQ+nHVBzedOYW3UL+iq9JV+MJoXzHWK7ianP9WkG0CFvijD1O/64i1zI5zGyE9uqDMkHebZeWNeVAeY4pvoJkMmHMy7jUhZXeKR7vnHyK5O/0fWX6/b1IE2NSGGyZA4qO+AIGxcBihC1h2vWrWYQB6cI5hgkJUTgc/73OE1OSsKx6aE4yOMt3W13794LP7scfYcJ/fo3by5ZfKs3BaSCzAISOH5ME3UqNA9/Z/S8EOFqvADu/aywlqNeMHcVN1KPS9UWRoSLabgiBhT2q0QEcq22FzLjf3HOLcT6eoYoOnWbo+Ry0AWOw1qeaag3GAvnHPolR4F/Z9BQElQMZCiUxl3MrJTJFWaazs7g3PAbi/SYStDxlzsb/m8EIk0gdYwZT3EETkxLpZWP/AWWLnjJl+XccZ3NZHFFj58pOlTfMMbBYWnEPY8AhCMApWb4h/U1dfEue2+5F2fFqxDxUiSIjOsBQt9H6tnadUEvLjbQq2DUK3Xtzjah4= 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)(39850400004)(396003)(346002)(376002)(136003)(230922051799003)(82310400011)(451199024)(1800799009)(64100799003)(186009)(46966006)(36840700001)(40470700004)(30864003)(2906002)(40480700001)(70206006)(8936002)(4326008)(316002)(8676002)(44832011)(40460700003)(5660300002)(41300700001)(2616005)(47076005)(83380400001)(36860700001)(107886003)(336012)(26005)(36756003)(31686004)(31696002)(81166007)(356005)(86362001)(53546011)(6666004)(82740400003)(6506007)(478600001)(70586007)(6512007)(6486002)(41533002)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2023 15:27:49.4279 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d6e4ef6a-e838-4884-bc25-08dbc4ee77d4 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: DBAEUR03FT055.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5390 X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,KAM_DMARC_NONE,NICE_REPLY_A,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 List-Id: On 10/3/23 18:23, Andrew Burgess wrote: > Luis Machado writes: > >> On 9/27/23 18:56, Andrew Burgess wrote: >>> Luis Machado writes: >>> >>>> Hi Andrew, >>>> >>>> On 9/25/23 10:57, Andrew Burgess wrote: >>>>> Luis Machado writes: >>>>>> Sure, that makes sense, and I don't disagree with that. But as I mentioned above, it is an >>>>>> orthogonal problem that might be better suited as its own patch/series. A more complete patch >>>>>> addressing this particular situation I stumbled upon. >>>>> >>>>> That's fine. I understand the urgency you have. For me, the only issue >>>>> I have here is that the new hook you add is to prevent GDB loading a >>>>> "broken" NT_GDB_TDESC. I'd also like this patch to include code that >>>>> prevents GDB from writing out "broken" NT_GDB_TDESC. >>>>> >>>>> I understand we're likely stuck with the "don't load the NT_GDB_TDESC" >>>>> hook due to broken GDB's already existing in the wild. That sucks, but >>>>> it is what it is. >>>>> >>>>> However, having identified some broken behaviour I think we really >>>>> should fix that at the same time as adding the work around. >>>>> >>>> >>>> Yes, I see your point and think it's reasonable. >>>> >>>>>>> When I originally added this code my problem case was RISC-V, where the >>>>>>> CSRs (control regs) for embedded targets can be different for each >>>>>>> target. The CSRs are just encoded as a blob, so unless you already know >>>>>>> which regs are present you're stuck. For real h/w the controller >>>>>>> (e.g. openocd) provides a tdesc (via target.xml), but for a core file we >>>>>>> needed a way to reacquire the tdesc. >>>>>>> >>>>>>> My assumption at the time that the tdesc we wrote would always be >>>>>>> correct, but clearly this isn't the case. >>>>>> >>>>>> That's true. With the introduction of dynamic target descriptions like sve and sme, this >>>>>> no longer holds true. >>>>> >>>>> OK. But is it really the case that the assumption is wrong, or is it >>>>> that the current code (that I added) is just using the wrong tdesc? >>>> >>>> For the general case, it is the wrong assumption because you can have threads >>>> with different tdesc's/gdbarches, and using a single NT_GDB_TDESC doesn't cover >>>> that part. >>>> >>>> Putting aside the threaded case, it can also be incorrect for the single-threaded >>>> case. >>>> >>>> Imagine you start up with a vector length of 256 bits (vg == 4). At this point the >>>> gdbarch/target description that gets stored in the inferior (the tdesc is still a >>>> per-inferior entry IMO) says the vector length is 256 bits. >>>> >>>> Now imagine we executed a few instructions and now the vector length is 128 bits >>>> (vg == 2). Though gdb will cope with it just fine during debugging, because >>>> aarch64/linux implements the thread_architecture hook, if we attempt to output >>>> a gcore core file, the current code (without your proposed patch) will dump >>>> the target description/gdbarch cached in the inferior. And that one says we >>>> have a vector length of 256 bits. >>>> >>>> So the tdesc is incorrect when we try to load the gcore file, if we trust the >>>> NT_GDB_TDESC note. The register data in the notes has the correct information >>>> though. >>> >>> I think we agree on the above. >>> >>>> Your attached patch fixes this because it uses the signalled thread's >>>> gdbarch/tdesc instead of the cached inferior gdbarch/tdesc. >>>> >>>> target_gdbarch can be a bit dangerous unfortunately, but we still have to use >>>> it in some places. >>> >>> That's unfortunate. I guess that might be because in some places we >>> have an inferior selected but no thread? >>> >>> It feels like the right solution is to transition GDB to only having a >>> per-thread gdbarch/tdesc, which would avoid problems like this in the >>> future. >>> >>>> >>>>> >>>>> I know you described the idea of updating gcore_elf_make_tdesc_note to >>>>> take a gdbarch* as orthogonal, but I really think this might be the way >>>>> to solve this problem. >>>>> >>>>> I've attached a patch at the end of this email that can be applied to >>>>> head of master BEFORE your patch series. This patch updates the >>>>> NT_GDB_TDESC generation to use the gdbarch of the signalled thread. >>>>> >>>>> Now, if I've understood how everything works, I believe that the >>>>> NT_GDB_TDESC that is emitted _with_ my patch should be good enough -- it >>>>> should be the correct tdesc for the signalled thread, which, if all >>>>> threads use the same tdesc, should be good enough. >>>>> >>>>> As a test, you can apply my patch, and then TEMPORARILY update >>>>> aarch64_use_target_description_from_corefile_notes to always return >>>>> true. Using such a GDB you should be able to create a core file, and >>>>> then load it back in correctly. >>>> >>>> Yes, that works correctly from testing on my end. So at a minimum that's >>>> already an improvement, as changing the vector length for one (or all threads, >>>> but with all of them still using the same vector length) during execution is a >>>> useful use case. Like a program setting up for some sve operation, and all of a >>>> someone wants to dump a core file. >>>> >>>>> >>>>> As I already mentioned, I acknowledge that we are stuck with the >>>>> aarch64_use_target_description_from_corefile_notes hook -- there are >>>>> broken GDBs in the wild. >>>> >>>> Though unfortunate, the most common core files are likely coming from crashes >>>> outside a debugging session (so not gcore). >>>> >>>>> >>>>> But, if I'm correct, then I think this is the best solution for now, >>>>> we're emitting a NT_GDB_TDESC that is mostly correct, but AArch64 will >>>>> continue to ignore it, just as you originally proposed. >>>>> >>>> >>>> Sorry, it took me a little bit to get some tests running on the simulator. Happy to >>>> report that I see no regressions in terms of testing with the changes you proposed for >>>> handling the signalled thread. >>>> >>>> Also, I checked the case I described above about a program starting with vg == 4 and then >>>> changing it to vg == 2 before we output a gcore file. >>>> >>>> When I load the corefile back in a patched gdb (and forcing gdb to use the tdesc, by always >>>> returning true in the aarch64-linux hook), I can see that the tdesc is the correct >>>> one (vector length indicating vg == 2). >>>> >>>> Without your patch, gdb used the inferior's cached gdbarch/tdesc to dump the NT_GDB_TDESC >>>> note, which means the vector length was vg == 4, when in reality it should've been >>>> vg == 2, as we had changed it before dumping the core file. >>> >>> This all sounds positive. >>> >>>> >>>>>> >>>>>>> >>>>>>> Right now RISC-V doesn't event override gdbarch_core_read_description, >>>>>>> so if we read the encoded tdesc after checking that gdbarch hook nothing >>>>>>> would change. >>>>>> >>>>>> That was my assessment back in the earlier versions of this series. >>>>>> >>>>>>> >>>>>>> For other architectures, if gdbarch_core_read_description is implemented >>>>>>> then we'll be back to using that, and that worked fine before. >>>>>>> >>>>>>> ... And if, in some future world we do implement >>>>>>> gdbarch_core_read_description for RISC-V then the solution seems >>>>>>> obvious, if there's a section containing CSRs, and there's also a >>>>>>> section containing a tdesc, then the RISC-V >>>>>>> gdbarch_core_read_description can just return nullptr, safe in the >>>>>>> knowledge the generic GDB code will load the encoded tdesc. >>>>>>> >>>>>>>> >>>>>>>> Except for some different names and tweaks, your proposed approach works correctly. >>>>>>>> >>>>>>>> I tested this and noticed the lack of NT_GDB_TDESC for a AArch64 Linux target >>>>>>>> with sve/sme support and one thread with a differing gdbarch. I also saw the note for >>>>>>>> a AArch64 Linux target without sve/sme support, or with sve/sme support but all threads >>>>>>>> having the exact same gdbarch. So that looks good to me. >>>>>>>> >>>>>>>> Would you like this extra code to be included as part of this >>>>>>>> particular patch? >>>>>>> >>>>>>> Yeah I think something like this should be added to this patch, we >>>>>>> should stop GDB creating incorrect core files I think. >>>>>> >>>>>> Got it. >>>>>> >>>>>> I'm afraid I'm going to need some clarification on ways forward with regards to this particular >>>>>> series. Do you still want this (or other) potential changes as part of this series or would you >>>>>> be ok with a follow-up patch/series to (try to, haven't gone in-depth yet) address this particular >>>>>> core file/gdbarch/threads situation? >>>>> >>>>> Here's what I propose:to output the cached gdbarch/ >>>>> >>>>> 1. Try the patch I've supplied here, if this works for you (see above) >>>>> then I think this is the best solution, we merge this, then go with v7 >>>>> of this patch unmodified, >>>> >>>> It did work. Thanks! >>>> >>>> But should we keep your suggested changes to check for distinct gdbarches in the threaded case? And >>>> not output NT_GDB_TDESC if we find multiple distinct gdbarch entries? >>> >>> I don't think so. As you've already said, in the core file case we >>> already don't support per-thread tdesc, even if we use the >>> aarch64_linux_core_read_description hook - that's only called once, and >>> will just generate a tdesc based on the main (signalled) thread as far >>> as I can tell. >>> >>> Telling GDB to dump per-thread NT_GDB_TDESC is trivial, but I haven't >>> looked at updating the core file code to read in per-thread tdesc, but I >>> suspect you'll (eventually) need to solve that problem even when using >>> the aarch64_linux_core_read_description hook. >>> >>> I know Simon has mentioned changing GDB to not write out NT_GDB_TDESC, >>> and I think that would be fine, however, I think we would still want my >>> proposed patch -- we should always write out the thread tdesc, not the >>> cached global one, as that is always going to be more accurate. >>> >>> My proposal then would be: we merge my patch to write NT_GDB_TDESC using >>> the per-thread tdesc, then you merge your original V7 version of this >>> patch with no other changes. >>> >>> Later, if we want, we can add a new hook to avoid writing the >>> NT_GDB_TDESC at all -- but that can come later, and would be in addition >>> to my proposed patch, not instead of it. >>> >>> If you and Simon are happy with this plan then I'll go ahead and push my >>> patch, this should unblock you, and you'll be able to merge this series. >>> >>> Let me know what you think, >> >> That sounds good to me. Thanks for going over this. >> >> Please let me know when you have pushed the NT_GDB_TDESC fixup. > > I've pushed the patch. > > I've included it again below, just for the record. > > Thanks, > Andrew Great. Thanks for addressing this.