From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80073.outbound.protection.outlook.com [40.107.8.73]) by sourceware.org (Postfix) with ESMTPS id C9AF63853541 for ; Thu, 9 Jun 2022 13:52:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C9AF63853541 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=H9XhB2BM/jskLQrrGoSe/rK2w9rkPIvRR7L/VNOIz1WL78S7HOgisnbfndLvQXUQ0klg20tKMzg3UT33kb0FyQVaMjFHD77Uo7pSHfFYAEcEhjKsUbQRveQOeFlyzmBU2SxuzEiOLusNs3Od4usgTwn/EjBio+9m0+2hS8N+zgD2wkkuiBBY7G3w2gbxJildonz6k0P7+Re6oBgfhlp5cw6H57cWH2Opyae8SDk8AYW9YoGvK0AL9nd9YRb0xnMbEBPep1FesGQ3Uag/SONWpwTfwj71zg8KiT/5JUUoSpMdj7rqSbGzs55UoiqeMDFcFhDxos8K3cVltYLtPmND2Q== ARC-Message-Signature: i=2; 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=kxo6TD3m8l76fe0abI8C6ZRl4WOvQW0lrGwMlL7yuGA=; b=RBUMQBna52XOQBt7YyQAHQVytoIkiQXU411os6JzZ1MB6KZuKoHxrLNYv/0/+Zc+bsK6s+/WZoPSpCr72tcxvfhuhJUDW7aUhWB46GIbC4soKxz6hTHK4Cafuhi0PpNVDtj7OirD9JWJTkK2tX+9wJa5tXaTR3kLRc2e3Jt/mPqGGTisCiTHvnXA+dy/cDZsq7RORZLGokfBVnUcymglR7xUE9vfj/XJo6vAz58s/uF+reusza33o6YClO0wRQv1isisQsEPmDWbAB1QNiQgtm4KKyT5GDhZERt0X90ZXt6kVpqsdeBgdIgsbSEinazj8icNdJWlTP3Lre7G8TGMrA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) Received: from AM5PR0301CA0001.eurprd03.prod.outlook.com (2603:10a6:206:14::14) by AM0PR08MB3748.eurprd08.prod.outlook.com (2603:10a6:208:fb::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.15; Thu, 9 Jun 2022 13:52:24 +0000 Received: from VE1EUR03FT016.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:14:cafe::36) by AM5PR0301CA0001.outlook.office365.com (2603:10a6:206:14::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.13 via Frontend Transport; Thu, 9 Jun 2022 13:52:24 +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 VE1EUR03FT016.mail.protection.outlook.com (10.152.18.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.12 via Frontend Transport; Thu, 9 Jun 2022 13:52:23 +0000 Received: ("Tessian outbound 5b5a41c043d3:v120"); Thu, 09 Jun 2022 13:52:23 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 5d9dd6b2c4b572c4 X-CR-MTA-TID: 64aa7808 Received: from 4a76dd8c54fb.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6634FF55-6F65-4D5B-860F-4EC2C6B801EA.1; Thu, 09 Jun 2022 13:52:16 +0000 Received: from EUR03-DBA-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 4a76dd8c54fb.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 09 Jun 2022 13:52:16 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MY8jSXMSxLllO/oPWMmD0DuHfTpoORvtvFLGfKXlV+vlv5jCPkWHylTSx6kfZygwhvD/XOJE0WzTocwCVWpsOFI7GzQZHhWVpXgA1M7ucXnVXb1UoQhI382bZIarGqLerpwEFc0pcs3JYeXYVOc2kAAkPaZe4EpS5z3Nvt651adW2X5qDIL54MZ0lKSkFdjIk5PG7NGFlfvg6pjjQZsD1Y+0e16LtWSPwtHF0vmmjVIOBE+QJ1CVALEl6YnzsoCLV2HDIpa/N2eH0bwnLvAtPDh37279eZt3rkmNvbwPSpE27Ky0AogrnF5vBZ6W6uMSnlAHGhgLWxJGsz8pN7vM9A== 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=kxo6TD3m8l76fe0abI8C6ZRl4WOvQW0lrGwMlL7yuGA=; b=dCw1Q1ZNc1Q0rbWACmhJ5573YMQxiddHfZQZlizpAcZzuI2s75KEPgjgN001uMdEKj56ElmHgd1M8evP7tof8XHB+puBx0iTzsi7UYQKJcKERdV0lnqPxBYg61WGlCIivBLYzD1q4RHTJpOC4fks9AioQ3WHOu1tNEC4RPoq81SNQJDHuegTl7NqOGc+R6UEKFe+ZoV9kR3Z9g8KGRVIe6+dH3FP6yGPvGzBwpnyPEP+d1Wc6TxxUrQmU1mr2nHbBsjYkVdPXgdC2/0QOkki52BnRZ5x4VFLf5p5/FRA1QlY/nXG6kHElJmvxa/ZptoHALdjt05wsHkG4dTwFL+Oag== 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 DBAPR08MB5621.eurprd08.prod.outlook.com (2603:10a6:10:1a3::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.11; Thu, 9 Jun 2022 13:52:14 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::d9c0:539c:a641:5735]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::d9c0:539c:a641:5735%2]) with mapi id 15.20.5332.013; Thu, 9 Jun 2022 13:52:14 +0000 Message-ID: <7ed3e032-5961-5dbb-06fe-6574a5e75791@arm.com> Date: Thu, 9 Jun 2022 14:52:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH] gdb/aarch64: fix 32-bit arm compatibility Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: <20220609123236.336949-1-aburgess@redhat.com> From: Luis Machado In-Reply-To: <20220609123236.336949-1-aburgess@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0057.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:60::21) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: cf8c04d0-ccc5-4f49-c49c-08da4a1f480e X-MS-TrafficTypeDiagnostic: DBAPR08MB5621:EE_|VE1EUR03FT016:EE_|AM0PR08MB3748:EE_ X-Microsoft-Antispam-PRVS: 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: IyBp8vxCiYtff3Kr1NlXSyTVpwYXLQDsFICytyfUzxIW4y4MWqrnJBcFX3P9rw40SQ9jgB9ncO22AhXjK54ncy+Vu7HC6uBbvr+I6v131r4c6DZuTPKEET2UW+60O/JZPsWw3GLRkD8m5f8CSkpUKYennH2XkpUgWNntiSppF3NxRhDzR9s5rdhq54Dj7+oI/3pZrSd4quXD9ymflhko0CS1UCXvynbDsGOVwfYOsHBp6P5dVkSJmMOx2ni3YZuobQXvQQfO75p+UxMiUg7RrmAaM71m/1sfxnS0WFTCcVgl6afd8T3IYBQ6HQNc9kyRwAceo49OLUm3u9p0slsox184Heg7fQDy6s/l2UsVXHnBZEpq7LZpx09f52n5YXt/o16V4yIn8DVIEN5aZFkFRv5kor4lC0tJuUTIRZwz14ty1sBpHxxor5BcE+mo1+HSCIx18IoSNxA+jvnKJJza80kdykykMNqSb537wcl/EqhsgkenaTzdwrXhyZEGp9PvCmRIoQLAMXsuCdaLPTM4/dq3KJZOrarSoY+cUZV7SnwzgtfTP7l4EBb4ShnYZ5NiUVG/DGQB/ZbQTXVDNvk0qOzWLvF/29tj8h/mNZ7Vn+M2rdI6/uU7VMIjr4JWygU9RQg253COfQC2IKT39mkDTUyAFCvE5QilpLeDEj3Ic9pqLLXAlihCXi4AnacRM+l0TmNhmTKISbfhyM3jnf1YAJuBX17cNhcy6xexak9EH9k1TgpFYXaS/IJOj3cbcjl8qAjxehYpHN+2llB/BLHw29DC7CBIDLaHFBIfs4djlAU8JEPbGXQQ6j6fX/L0dA4u 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:(13230001)(4636009)(366004)(84970400001)(66556008)(2906002)(316002)(6666004)(83380400001)(66946007)(6506007)(6512007)(53546011)(26005)(2616005)(86362001)(66476007)(31696002)(186003)(5660300002)(508600001)(31686004)(44832011)(8676002)(36756003)(6486002)(38100700002)(8936002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5621 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: VE1EUR03FT016.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: d62ac459-6712-4710-c7fa-08da4a1f41f0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: wcod04JynC38Nr1KgdNISbtCc7c7ktrx/2VdwXo8BxE3oKxwl1YX1sfg5zagY/LxuVo5eH7mI1ljR5PQ75BnLkhSdfMcTe3SE1OiqrPIAQlUuC3P4wOZDgGCo8/sOF2bxVa6tQZCl750tO/wkTsyg7aZ3+tY4DCt/V5jiInx7m9kEzL+v66lihfDYsBFjA3EkyWi7sUBo5EGWX6s6PMrtFCwB3bZRLLIpF/Og+kCmO8pJ829WVkQ5S9DrLWu36OVE3gVXKM3WK8SgZtysuD55Ei5HcVc7A+a9l7Eenfw36g8WjOMarqC1eXs+BnX4DaiNaSHdgvWLneB1yI6ecOTNOlGdEEnG/6+8lLFt4BAFSwNmEPr3H4CMaWiNMAfmRrnXQhmRUbYr6yDcAhHNiH6QNwNUq8pgn6QlZY1UjCrDjGejkQzIWEdJz4jL+X5WXDNW1eJLwoOcWlz37WW4E7ELgfHGTAb6sGlNV2iSKU3HbLNonfsbl1JYKKBukFbFbocUEvwcxoZJU21WOAex391U1aXCJSggjOCxuBponAfo11H7I2/u1/+J6XCbzMIfWIM6rXvbUFWsPrRMh4s4Ns8XVz6Bbiajh7xR77UMMRA+SscXggZwvM/sc4pJ/5Va4bM0ahKEpLTo/ukO/BDXRl415ctCZvkuWJ90bEHIxwaMbOpZ8Cez1Gzl6HfwrunlBC7jmdCsTJ8fwwkDmSwCoDZg8V+U4sg1TvCToq7/T6fhGJUUneQPq4JvGviE9I5ipS6v2Vpl39KTO8zYNt/kXgfk4AsXHYmdM9i8BHcczKmZb4= 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:(13230001)(4636009)(40470700004)(46966006)(36840700001)(8676002)(81166007)(36860700001)(31686004)(356005)(82310400005)(70586007)(70206006)(316002)(36756003)(83380400001)(6506007)(6486002)(2906002)(6666004)(508600001)(53546011)(6512007)(26005)(40460700003)(8936002)(186003)(86362001)(2616005)(5660300002)(336012)(47076005)(31696002)(84970400001)(44832011)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2022 13:52:23.8309 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cf8c04d0-ccc5-4f49-c49c-08da4a1f480e 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: VE1EUR03FT016.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3748 X-Spam-Status: No, score=-13.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, 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.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2022 13:52:30 -0000 On 6/9/22 13:32, Andrew Burgess via Gdb-patches wrote: > GDB's ability to run 32-bit ARM processes on an AArch64 native target > is currently broken. The test gdb.multi/multi-arch.exp currently > fails with a timeout. > > The cause of these problems is the following three functions: > > aarch64_linux_nat_target::thread_architecture > aarch64_linux_nat_target::fetch_registers > aarch64_linux_nat_target::store_registers > > What has happened, over time, is that these functions have been > modified, forgetting that any particular thread (running on the native > target) might be an ARM thread, or might be an AArch64 thread. > > The problems always start with a line similar to this: > > aarch64_gdbarch_tdep *tdep > = (aarch64_gdbarch_tdep *) gdbarch_tdep (inf->gdbarch); > > The problem with this line is that if 'inf->gdbarch' is an ARM > architecture, then gdbarch_tdep will return a pointer to an > arm_gdbarch_tdep object, not an aarch64_gdbarch_tdep object. The > result of the above cast will, as a consequence, be undefined. > > In aarch64_linux_nat_target::thread_architecture, after the undefined > cast we then proceed to make use of TDEP, like this: > > if (vq == tdep->vq) > return inf->gdbarch; > > Obviously at this point the result is undefined, but, if this check > returns false we then proceed with this code: > > struct gdbarch_info info; > info.bfd_arch_info = bfd_lookup_arch (bfd_arch_aarch64, bfd_mach_aarch64); > info.id = (int *) (vq == 0 ? -1 : vq); > return gdbarch_find_by_info (info); > > As a consequence we will return an AArch64 gdbarch object for our ARM > thread! Things go downhill from there on. > > There are similar problems, with similar undefined behaviour, in the > fetch_registers and store_registers functions. > > The solution is to make use of a check like this: > > if (gdbarch_bfd_arch_info (inf->gdbarch)->bits_per_word == 32) > > If the word size is 32 then we know we have an ARM architecture. We > just need to make sure that we perform this check before trying to > read the tdep field. > > In aarch64_linux_nat_target::thread_architecture a little reordering, > and the addition of the above check allows us to easily avoid the > undefined behaviour. > > For fetch_registers and store_registers I made the decision to split > each of the functions into two new helper functions, and so > aarch64_linux_nat_target::fetch_registers now calls to either > aarch64_fetch_registers or aarch32_fetch_registers, and there's a > similar change for store_registers. > > One thing I had to decide was whether to place the new aarch32_* > functions into the aarch32-linux-nat.c file. In the end I decided to > NOT place the functions there, but instead leave them in > aarch64-linux-nat.c, my reasoning was this: > > The existing functions in that file are shared from arm-linux-nat.c > and aarch64-linux-nat.c, this generic code to support 32-bit ARM > debugging from either native target. > > In contrast, the two new aarch32 functions I have added _only_ make > sense when debugging on an AArch64 native target. These function > shouldn't be called from arm-linux-nat.c at all, and so, if we places > the functions into aarch32-linux-nat.c, the functions would be built > into a 32-bit ARM GDB, but never used. > > With that said, there's no technical reason why they couldn't go in > aarch32-linux-nat.c, so if that is preferred I'm happy to move them. > > After this commit the gdb.multi/multi-arch.exp passes. > --- > gdb/aarch64-linux-nat.c | 114 +++++++++++++++++++++++++++++++++++----- > 1 file changed, 100 insertions(+), 14 deletions(-) > > diff --git a/gdb/aarch64-linux-nat.c b/gdb/aarch64-linux-nat.c > index ff5c4c0a212..d58ad0143a2 100644 > --- a/gdb/aarch64-linux-nat.c > +++ b/gdb/aarch64-linux-nat.c > @@ -46,6 +46,7 @@ > > #include "gregset.h" > #include "linux-tdep.h" > +#include "arm-tdep.h" > > /* Defines ps_err_e, struct ps_prochandle. */ > #include "gdb_proc_service.h" > @@ -485,11 +486,11 @@ store_tlsregs_to_thread (struct regcache *regcache) > perror_with_name (_("unable to store TLS register")); > } > > -/* Implement the "fetch_registers" target_ops method. */ > +/* The AArch64 version of the "fetch_registers" target_ops method. Fetch > + REGNO from the target and place the result into REGCACHE. */ > > -void > -aarch64_linux_nat_target::fetch_registers (struct regcache *regcache, > - int regno) > +static void > +aarch64_fetch_registers (struct regcache *regcache, int regno) > { > aarch64_gdbarch_tdep *tdep > = (aarch64_gdbarch_tdep *) gdbarch_tdep (regcache->arch ()); > @@ -534,11 +535,48 @@ aarch64_linux_nat_target::fetch_registers (struct regcache *regcache, > fetch_tlsregs_from_thread (regcache); > } > > -/* Implement the "store_registers" target_ops method. */ > +/* A version of the "fetch_registers" target_ops method used when running > + 32-bit ARM code on an AArch64 target. Fetch REGNO from the target and > + place the result into REGCACHE. */ > + > +static void > +aarch32_fetch_registers (struct regcache *regcache, int regno) > +{ > + arm_gdbarch_tdep *tdep > + = (arm_gdbarch_tdep *) gdbarch_tdep (regcache->arch ()); > + > + if (regno == -1) > + { > + fetch_gregs_from_thread (regcache); > + if (tdep->vfp_register_count > 0) > + fetch_fpregs_from_thread (regcache); > + } > + else if (regno < ARM_F0_REGNUM || regno == ARM_PS_REGNUM) > + fetch_gregs_from_thread (regcache); > + else if (tdep->vfp_register_count > 0 > + && regno >= ARM_D0_REGNUM > + && (regno < ARM_D0_REGNUM + tdep->vfp_register_count > + || regno == ARM_FPSCR_REGNUM)) > + fetch_fpregs_from_thread (regcache); > +} > + > +/* Implement the "fetch_registers" target_ops method. */ > > void > -aarch64_linux_nat_target::store_registers (struct regcache *regcache, > +aarch64_linux_nat_target::fetch_registers (struct regcache *regcache, > int regno) > +{ > + if (gdbarch_bfd_arch_info (regcache->arch ())->bits_per_word == 32) > + aarch32_fetch_registers (regcache, regno); > + else > + aarch64_fetch_registers (regcache, regno); > +} > + > +/* The AArch64 version of the "store_registers" target_ops method. Copy > + the value of register REGNO from REGCACHE into the the target. */ > + > +static void > +aarch64_store_registers (struct regcache *regcache, int regno) > { > aarch64_gdbarch_tdep *tdep > = (aarch64_gdbarch_tdep *) gdbarch_tdep (regcache->arch ()); > @@ -573,6 +611,43 @@ aarch64_linux_nat_target::store_registers (struct regcache *regcache, > store_tlsregs_to_thread (regcache); > } > > +/* A version of the "store_registers" target_ops method used when running > + 32-bit ARM code on an AArch64 target. Copy the value of register REGNO > + from REGCACHE into the the target. */ > + > +static void > +aarch32_store_registers (struct regcache *regcache, int regno) > +{ > + arm_gdbarch_tdep *tdep > + = (arm_gdbarch_tdep *) gdbarch_tdep (regcache->arch ()); > + > + if (regno == -1) > + { > + store_gregs_to_thread (regcache); > + if (tdep->vfp_register_count > 0) > + store_fpregs_to_thread (regcache); > + } > + else if (regno < ARM_F0_REGNUM || regno == ARM_PS_REGNUM) > + store_gregs_to_thread (regcache); > + else if (tdep->vfp_register_count > 0 > + && regno >= ARM_D0_REGNUM > + && (regno < ARM_D0_REGNUM + tdep->vfp_register_count > + || regno == ARM_FPSCR_REGNUM)) > + store_fpregs_to_thread (regcache); > +} > + > +/* Implement the "store_registers" target_ops method. */ > + > +void > +aarch64_linux_nat_target::store_registers (struct regcache *regcache, > + int regno) > +{ > + if (gdbarch_bfd_arch_info (regcache->arch ())->bits_per_word == 32) > + aarch32_store_registers (regcache, regno); > + else > + aarch64_store_registers (regcache, regno); > +} > + > /* Fill register REGNO (if it is a general-purpose register) in > *GREGSETPS with the value in GDB's register array. If REGNO is -1, > do this for all registers. */ > @@ -793,22 +868,33 @@ aarch64_linux_nat_target::can_do_single_step () > return 1; > } > > -/* Implement the "thread_architecture" target_ops method. */ > +/* Implement the "thread_architecture" target_ops method. > + > + Returns the gdbarch for the thread identified by PTID. If the thread in > + question is a 32-bit ARM thread, then the architecture returned will be > + that of the process itself. > + > + If the thread is an AArch64 thread then we need to check the current > + vector length; if the vector length has changed then we need to lookup a > + new gdbarch that matches the new vector length. */ > > struct gdbarch * > aarch64_linux_nat_target::thread_architecture (ptid_t ptid) > { > - /* Return the gdbarch for the current thread. If the vector length has > - changed since the last time this was called, then do a further lookup. */ > - > - uint64_t vq = aarch64_sve_get_vq (ptid.lwp ()); > - > - /* Find the current gdbarch the same way as process_stratum_target. Only > - return it if the current vector length matches the one in the tdep. */ > + /* Find the current gdbarch the same way as process_stratum_target. */ > inferior *inf = find_inferior_ptid (this, ptid); > gdb_assert (inf != NULL); > + > + /* If this is a 32-bit architecture, then this is ARM, not AArch64. > + There's no SVE vectors here, so just return the inferior > + architecture. */ > + if (gdbarch_bfd_arch_info (inf->gdbarch)->bits_per_word == 32) > + return inf->gdbarch; > + > + /* Only return it if the current vector length matches the one in the tdep. */ > aarch64_gdbarch_tdep *tdep > = (aarch64_gdbarch_tdep *) gdbarch_tdep (inf->gdbarch); > + uint64_t vq = aarch64_sve_get_vq (ptid.lwp ()); > if (vq == tdep->vq) > return inf->gdbarch; > LGTM. Thanks for the patch!