From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on2049.outbound.protection.outlook.com [40.107.8.49]) by sourceware.org (Postfix) with ESMTPS id 8B7C23858D20 for ; Thu, 28 Sep 2023 08:24:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8B7C23858D20 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=gO5f1QMqEsDEfTxHem61KtTorda5TbMeHadS8piYH8g=; b=Z14zAAYgVwiW5mJokjEllvrMnHnWb6AoXzhRmbNTxHOPiWJ5Whwzt4qFdOg5d8RBB1F6olGRcXcI0x1g2Apv4SVvKz87jIxQALgPdlcnuVVFPyjCJm5c8DQzAZOrQIUvnoN4/dnnEjgaQlWwvGJ7ZhzLRWyKmWrtEniQ2ZI0IcE= Received: from AM6P193CA0087.EURP193.PROD.OUTLOOK.COM (2603:10a6:209:88::28) by AS4PR08MB8141.eurprd08.prod.outlook.com (2603:10a6:20b:58c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.21; Thu, 28 Sep 2023 08:24:02 +0000 Received: from AM7EUR03FT008.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:88:cafe::7c) by AM6P193CA0087.outlook.office365.com (2603:10a6:209:88::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.24 via Frontend Transport; Thu, 28 Sep 2023 08:24:02 +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 AM7EUR03FT008.mail.protection.outlook.com (100.127.141.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.25 via Frontend Transport; Thu, 28 Sep 2023 08:24:02 +0000 Received: ("Tessian outbound 9aeaca65ec26:v211"); Thu, 28 Sep 2023 08:24:01 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: bcc819b214e579d0 X-CR-MTA-TID: 64aa7808 Received: from e16bdb096ee8.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id B841F021-DB80-45BA-85FB-A67F3FE4EA53.1; Thu, 28 Sep 2023 08:23:53 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e16bdb096ee8.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 28 Sep 2023 08:23:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ahSpIgfw8q3N7eGmLS4dfEuk9r4H/nxz+bfhlNAZkz4L003f5brGQUoA/1JgV8QPiNY4Lb18N9xm8qFAchbSaY8mg1N4nXvTbLGVMrktNO0U8uiqZRZx+HQfll/eh/8jI1kqtiCaXVIoYHDBCZjWegGJQ+Um7dPe0cyhogvyvLcU9xoPWl2eNXJcnXG5wZKshF1PLBR9ncaW14YFS5vpBYBugiwCIqOvRRDgdAVxlM+Rfbbw+Zj6X8Zz2on636dYS4qSXHwThBXmlOp+cdvWSwJto8YkqL0Ac0zj2Zdb2+l9MLEvL640Z/Nq4cPa72LbZk7TK2qgHTZbYKVlrB1mrg== 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=gO5f1QMqEsDEfTxHem61KtTorda5TbMeHadS8piYH8g=; b=LVYYL/YXnDJs+xyO+Wg7azZTAVorJQST+mZsQweNckm+Y4UZbkMDR4mGVJ9H+MuFys9dPbUNxkVCqkD8t2usGwuNNxMsd42U8CuMFGtprO+KdCx56PTQgrvmHbhbdkRROugrF081QkMSWW5e/AaupFcOSqolPIPOb93K3TBB5zDhMlgYsPnhKsKBNJEfBe+h6LyaeyhE9mdL/h8A6BzewAQ7QwHKmXOzvRuDJGKg0d8dbYO6CkB8HHAZZyNQE5/5s4ZzTUgcmNi9ApKLrZcvOEYVnoxcroMysPUDZAcpT++3FYzd5+y3ptgHgoUWPpAWEm77NqkDbYDDbnJrhh4dgQ== 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=gO5f1QMqEsDEfTxHem61KtTorda5TbMeHadS8piYH8g=; b=Z14zAAYgVwiW5mJokjEllvrMnHnWb6AoXzhRmbNTxHOPiWJ5Whwzt4qFdOg5d8RBB1F6olGRcXcI0x1g2Apv4SVvKz87jIxQALgPdlcnuVVFPyjCJm5c8DQzAZOrQIUvnoN4/dnnEjgaQlWwvGJ7ZhzLRWyKmWrtEniQ2ZI0IcE= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from AM6PR08MB3911.eurprd08.prod.outlook.com (2603:10a6:20b:80::27) by AS4PR08MB7735.eurprd08.prod.outlook.com (2603:10a6:20b:512::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.28; Thu, 28 Sep 2023 08:23:51 +0000 Received: from AM6PR08MB3911.eurprd08.prod.outlook.com ([fe80::146d:342:e715:2475]) by AM6PR08MB3911.eurprd08.prod.outlook.com ([fe80::146d:342:e715:2475%7]) with mapi id 15.20.6838.016; Thu, 28 Sep 2023 08:23:51 +0000 Message-ID: Date: Thu, 28 Sep 2023 09:23:47 +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> From: Luis Machado In-Reply-To: <87fs2zwlda.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO6P265CA0013.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:339::19) To AM6PR08MB3911.eurprd08.prod.outlook.com (2603:10a6:20b:80::27) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: AM6PR08MB3911:EE_|AS4PR08MB7735:EE_|AM7EUR03FT008:EE_|AS4PR08MB8141:EE_ X-MS-Office365-Filtering-Correlation-Id: ab85d706-1fe7-4f8a-db49-08dbbffc457a 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: 7XavFdctKTkVLlT8h2l/K2/+awDQzr7r7EwzuqH/yO1/hNs+fBtI+CovgWg/puMVruhIAVUzGbkEp4QNse1N9dZqhn/8yJi95+eEOjmTBmz6DfvGvcEQgKY+OX4Pou7qfUtJ4XUGXbWqQgo+uO9gmvx0TKuhXhQ34xWa/UMQB9brrnZWifyAw+gz6QRLTKc2Lj3pS7x9ZW0dFjkuqtUteDo/1bxL1zOySnkIM7XyLuQu/XZAPLfJR5WAx6gP1iOpTOjYG/B6j8Zi1U/9GZzEyteQ3PYlWd5dIzFRJuXiV92I5LmfQyE//iw/RzEa/76o42U62iKc3QxZ/88ikMJcu0AtHjqXubPjK2Tg/88sdDz2ly5aJbRjOIP7C26oS7+VldkpGaKIkRAmYWmAf3uXhX9pAU54PY7iy9cDJQvg/EayVaAYBEy3KiEdl71isQb9CYTDCjseoddqCeHx5dgK+FwMOnGy9io7jjkzJ6DbqnUVxv+gck7nLPsfNqoU9UZGplCWeoiWFGK1UB3VRAHNDgBh69u/zPqwyEvR+8u7qj4asROIyhwnoidtbBHuvB48y5ItHAblGknAOyyu5axxslbAGJoGUmfY5X8Iar/XDka3H+A1hGlK8KSYcsR9cQ2LdQGp5zG7t4+xqnFoIoxeBQ3FN04raA0s6qjQRVniqI8= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR08MB3911.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(39860400002)(366004)(396003)(376002)(346002)(136003)(230922051799003)(1800799009)(64100799003)(451199024)(186009)(26005)(83380400001)(66556008)(66476007)(66946007)(36756003)(6512007)(316002)(6506007)(6486002)(86362001)(31696002)(53546011)(38100700002)(6666004)(2616005)(478600001)(30864003)(5660300002)(4326008)(31686004)(8936002)(2906002)(8676002)(44832011)(41300700001)(41533002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7735 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: AM7EUR03FT008.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: de1c0d9f-a6bc-4703-37be-08dbbffc3f08 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FQUrOVutpEaEnLq/B77frQ9IB+zkyT2pF0nO2cnS9bVJu092MbdAQf0fQU/d9elhW/aDw/UuQyEKeiaeGvLJ89CYH6kNvZJQzEpaQrocI0bmhoWJ1uK6bUmoYEUGOH1VBxFN0AKfPNASS1kd4hH4isBPkt1dCsfjxufKJ/F3N9/OPmD6wLWtE626Ekb4HntHyOTchapIWEImjhlfa5fw0Jjn/DoAJBADr8/dkjOL2XNLIffUKZq9LcAwiEqAiDz0cLa0ZaDiYqE92xBUvieOoEeieABIfspGyhymLESM1zQ6DVxYsqta8vRc4YlT3wjT0N+rb+/ZFAD2IIW7XCR8I7eCgOjUEyb969ygJIV270msAdLrc/EeojoxGWvwzHffmX8t+HrnMXaC3pu8CUH98Y15ArNxGdsvoR6E81jN78vLf2xZKab9ung2WAduB3p5kOqUnKZZwW3WO0OeMm24JWR1LXjqGVcUM7kXlTBnQL0TBvS8y4rn9IVTjQ+/fHnNlZEUZDAeh24iZdN8dxKAaGUNiLP2o5nBPkoKzIX3LeCBn0pjmznWHeLCVwcaTuAj2tS0/e6O9ZLE2DVHGVuwWtZgJ1/H8xfRdX1dhNWKTo/KV1SYMB2K4fYHzV1XgWo19Y/f5xPaKZuMIOjQxirOYB5QWHPVP9S3ceA7KN6j3DSNWjifLRbtBnd16aWNGtTnc7YrwFvEXIcdGj5KxrZerzYkoxJoMXXJgDuxb2A4JyInqLjf2DQj6comQZBBbBenDW5eFdKFEXLQLN9GQ5yI6fB9WkAQ+2A397BU1pJeAmU= 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)(136003)(346002)(376002)(396003)(39860400002)(230922051799003)(451199024)(64100799003)(1800799009)(186009)(82310400011)(36840700001)(46966006)(40470700004)(83380400001)(6512007)(6506007)(6486002)(107886003)(6666004)(478600001)(53546011)(4326008)(336012)(26005)(5660300002)(36756003)(30864003)(44832011)(2906002)(8936002)(70206006)(41300700001)(316002)(70586007)(47076005)(356005)(36860700001)(86362001)(8676002)(31696002)(82740400003)(81166007)(2616005)(40480700001)(31686004)(40460700003)(41533002)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2023 08:24:02.0306 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ab85d706-1fe7-4f8a-db49-08dbbffc457a 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: AM7EUR03FT008.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB8141 X-Spam-Status: No, score=-6.6 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 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. Regards, Luis