From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id dLOLG1bREmUTcR0AWB0awg (envelope-from ) for ; Tue, 26 Sep 2023 08:40:54 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=tO1dacT0; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 6252C1E0C3; Tue, 26 Sep 2023 08:40:54 -0400 (EDT) Received: from server2.sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (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 4ECFF1E092 for ; Tue, 26 Sep 2023 08:40:52 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9817B3858D35 for ; Tue, 26 Sep 2023 12:40:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9817B3858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1695732051; bh=4slVPUBj17epcmycpvkumSc3qgpEuZBZ9SzqOdpvqa0=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=tO1dacT06/JaNTgLhOo5RlQheQhkWwAK32X2/m8zZC4bceo7p3Rmn7Td3JwkZr2LR Ii1QRFHvddxN3RSHSEG3iukwhNM5bPtfuduXZ+2bgZTkTniARQJMUKRUJbHFkatend XW48plhxUOSn5xWBNVp+/d5dlM2NIDGibefrCiio= Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2063.outbound.protection.outlook.com [40.107.21.63]) by sourceware.org (Postfix) with ESMTPS id 847283858D35 for ; Tue, 26 Sep 2023 12:40:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 847283858D35 Received: from DUZPR01CA0168.eurprd01.prod.exchangelabs.com (2603:10a6:10:4b3::24) by GVXPR08MB7871.eurprd08.prod.outlook.com (2603:10a6:150:17::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.28; Tue, 26 Sep 2023 12:40:16 +0000 Received: from DBAEUR03FT039.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:4b3:cafe::b0) by DUZPR01CA0168.outlook.office365.com (2603:10a6:10:4b3::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.35 via Frontend Transport; Tue, 26 Sep 2023 12:40:16 +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 DBAEUR03FT039.mail.protection.outlook.com (100.127.142.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.19 via Frontend Transport; Tue, 26 Sep 2023 12:40:16 +0000 Received: ("Tessian outbound 30c9f5e988c5:v175"); Tue, 26 Sep 2023 12:40:16 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 294e76efed62cb7c X-CR-MTA-TID: 64aa7808 Received: from 7628481ffd5f.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 26D2E425-5261-463C-9343-7B33863596DF.1; Tue, 26 Sep 2023 12:40:08 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 7628481ffd5f.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 26 Sep 2023 12:40:08 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=it+CXj8omFiOcyt771irsgLiHK94XpSEsVHk0QcYfpHauLAXwBeXt/lWBCva+JM3j+Kn1XHvekE3wTs7HARW+7Hz5+DEbt9Q+DOQlTMd0QXklvk9KvRIq0tXDl2KX8uMWgVRDPHsiKCCOr55hdRZjV720ODuDdoHmZft6iR483Fv7Q+eaLrRafYn/O3JaRVErbX2U9H1+zv+WpMG3tcqMpbYfFXhMBU/iNg2dISmxH8e0KrosuDEcDW/cTBHOrMQeXjArDbK1a3WDc7fAsiixuODqX/wXkXMT04/qIawUZXlN2V3EKfnvHn3G8Ce3X3ufbo20SO0tuhre1LZRgv/3w== 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=4slVPUBj17epcmycpvkumSc3qgpEuZBZ9SzqOdpvqa0=; b=A4v6JEwZVSdgVbtx7f8FW/huTjHpbK5AUFqlGuCZmTGe6DSnGz9xmoCVOtL5ntvNFJocFSWhBsiDTLScidOV6p4/x0OVCaMhs/pViWrnRNsyCU/g012GKMv7xO8b2W/hhHH+h2AXVaUF1aVlnCnm3AZG8xhXbs8LsWHcrQBdX2SCvj2zAVc/wJggwUhGqkXf/D7m7MMikhilqWQe4J2LQ/rUWihw0jmtjy/CcqYT8o1B8MZejjZaoVhexxuzaaG6RWvUA17hsiSHDpQNy4NJxbbgFpo140BLM0ihRs29Yeo+3QqCkdPxnbCY3HzTqPxDU5zNEe2ZCgihUOhk2viMAQ== 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 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 DB9PR08MB6425.eurprd08.prod.outlook.com (2603:10a6:10:261::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.28; Tue, 26 Sep 2023 12:40:07 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::7743:60fe:4859:2df2]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::7743:60fe:4859:2df2%6]) with mapi id 15.20.6813.027; Tue, 26 Sep 2023 12:40:06 +0000 Message-ID: Date: Tue, 26 Sep 2023 13:39:58 +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> In-Reply-To: <87bkdqy3qe.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SA1P222CA0093.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:35e::18) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|DB9PR08MB6425:EE_|DBAEUR03FT039:EE_|GVXPR08MB7871:EE_ X-MS-Office365-Filtering-Correlation-Id: 0e40ff98-d107-4e3f-b742-08dbbe8dbc42 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: 9SFbG+GU2SupN+z4PtO8Pr1Kp0pQc7fQhWfhutX+ngWyaNF9YIu7vMHQCva6Apk/bFPUgzqWooA3YOhxa9rFdKX047FJLU8TduOo80uQFvmcb9SfIlghMDoII/ldaEYRtYA3RaPit063+B6vPwvWNY2qFgYDepsNGU8fMAj/abS+YhF8WqQyOqBz9vjX1C0qNowF3wnTRB6W/k6cGwmpUxxqjjq8rOqFglTBcKHiWuqwNqbpokdzjSfwL/QNenDWaLgkVNURirxp3QOZNLObfiOX19QegZ59LrzthNJsEJ2TYBaNjiq80HuLvcRROY0W5NNdF3DNadlPy9cGw84zPoT76r8E+v6OGGaPqHjdY7b57Dz0XBdfhje19zSslFyj6viDtZygNc7SlEqcmy+mkSQw/NGAltklgjHYehPlXkBOaJb6M6FSUbOWp48ZPZ/qqSfjVwvkOD46Zry6luE143Aiswpz/WSCBdAPj1YGDVVgzBIg1811OG2J+rTpAasqfjQ23nzm2GIIsF12xpWymc+D7dGetTY0GS/9eY2Dhdgijxq98+gr5b3DLzA8j7w2i/LmtVT+8/HItE/8BV90byyqQsSSwHGOQ13wNTn+b7Z+0Ff8GsK9ZCB+GHf1wTtOnb/wkb/BI9BkkuUQLV4uDB3Fz28ttTlLtODNEYIbsZs= 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)(39860400002)(366004)(396003)(346002)(376002)(136003)(230922051799003)(186009)(1800799009)(451199024)(6512007)(6486002)(53546011)(6506007)(6666004)(83380400001)(86362001)(31696002)(38100700002)(36756003)(2616005)(26005)(2906002)(316002)(41300700001)(8936002)(66946007)(66476007)(31686004)(4326008)(478600001)(8676002)(5660300002)(44832011)(66556008)(41533002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6425 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: DBAEUR03FT039.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: dcc0294b-47de-46d6-76a4-08dbbe8db661 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ujsubXqJn21Mhj/7wbsID+zlXSIH/+k/KDbnEAyolmj6s7NKjm2JXoqhp5mwxiDiS+AlbP1eaRzOFOWiYUo3j0flDIyVy/xx95FnUmzRDAs5Jt/V/hwNnlivHTI63NUvnQPRWSC4y45bQqTYHrRP0+UpFbz/8GE1pFfkrYFlYXJ06odLfXfGhIRwzLopBHTRX3nFtHirxKntdjfRUkJWzUUEBMawl4oTAczK1D/ObarkQL14d2hkh4ZvBobyqOjBRBSSfDrAmHJT9P7R8uYn5J0ZaFMcKCeGg3XSk51uc7DnDH1Y7BQn+OHSzx8Hjk5ApwyFw1IHPaeYW29pzVFnvuphLYOLYhBOHsaBswJekI1FqIb+bnhzZbt8CbCwKFZNIHqQYxn2k1LBRLsOigyviFy/HL63wCZxVr0ieJlPubi4Uv+pyYJbswMJPJt+svEcax2oEVNBZHkq695H/n5xDXVlqKuzjgm8UeBpi1msy+IsdbMrQSHl3YeIw5+B2hFfqDjSxxpmznKrngbP13ApTwiXoeD2Wo0k3pyRFonrW5Mbi9ZDexehgcVOGF7AprREezsRpB4SwiMTsRbfA19LJN/CLc+NXn9QOdOMP/VAJeR/Jf8JlWTE33u4NmfGCqkr3ZJLrVpgYXJ6FSTsExJE407Rn2qRjPwf1SsAk+hcUi+rb32wp2jkvHHNfhPP+/oFVJ7TP5CtuweV8TE0U7M2RBdbe6nlg35xgr0Ky24i/YHvaUTaaOqbsbZr8tW27uHLzfRNJBS44QDjXHiioJSMTHFka/UD1OlX4QLZe2HHObM= 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)(396003)(136003)(376002)(346002)(39860400002)(230922051799003)(186009)(451199024)(82310400011)(1800799009)(36840700001)(46966006)(40470700004)(86362001)(31696002)(36756003)(31686004)(40480700001)(6666004)(53546011)(70586007)(6506007)(5660300002)(26005)(70206006)(6512007)(2616005)(336012)(41300700001)(107886003)(44832011)(316002)(4326008)(8676002)(8936002)(478600001)(47076005)(2906002)(40460700003)(356005)(82740400003)(6486002)(81166007)(36860700001)(83380400001)(41533002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2023 12:40:16.1055 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0e40ff98-d107-4e3f-b742-08dbbe8dbc42 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: DBAEUR03FT039.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB7871 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 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: , From: Luis Machado via Gdb-patches Reply-To: Luis Machado Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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. 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. > > 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. >> >>> >>> 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?