From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2058.outbound.protection.outlook.com [40.107.21.58]) by sourceware.org (Postfix) with ESMTPS id 20BB8385734D; Wed, 20 Apr 2022 06:59:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 20BB8385734D Received: from DU2PR04CA0183.eurprd04.prod.outlook.com (2603:10a6:10:28d::8) by PR3PR08MB5770.eurprd08.prod.outlook.com (2603:10a6:102:87::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Wed, 20 Apr 2022 06:59:51 +0000 Received: from DB5EUR03FT037.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:28d:cafe::b2) by DU2PR04CA0183.outlook.office365.com (2603:10a6:10:28d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20 via Frontend Transport; Wed, 20 Apr 2022 06:59:51 +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; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT037.mail.protection.outlook.com (10.152.20.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5186.14 via Frontend Transport; Wed, 20 Apr 2022 06:59:51 +0000 Received: ("Tessian outbound ac9bb5dd84f6:v118"); Wed, 20 Apr 2022 06:59:51 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 1639fee9e3420cb0 X-CR-MTA-TID: 64aa7808 Received: from 333ebe77ce1b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8009824E-ADCD-4813-B4E6-6B11674E4022.1; Wed, 20 Apr 2022 06:59:44 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 333ebe77ce1b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 20 Apr 2022 06:59:44 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AL2pB0zEgmXusP7CLJSrrPyYv2+cjHJF+PUS57rvkH8YgzEXCGoplMzSwtA0t1spyPsrNVkAdgiVF9pKxLfuaxGN+vtOZJKminYUgx3JdfxFjtUT8EtMRnNiXP3KXJ3/QOogi3THIVI58Bx6j5P+cs6uxufas2McQKG9rmBHzY3vXsL3MjprmQJWKxeX/nC+xZKWHhWREsR0PHsQ0QlJAzkx1bIXwYHceQzb1NjJhIzQYLEr4zkn8FsRDokqNotDkknpyWeOPdM0DqATqj0pc0j8YP7yAJxbA8Fo96hwGu4dD+H7WrSbb7AD3XRUFj2ZdA1yhOWkX9ZveF5sGvuYtw== 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=8N1t8bj/+SAJqEb4/Qp6mqwYZnyZKhHtCdyCSVc+4wM=; b=FrBCQG8v6T5SchNWx2Mv/CyqzGj5eB1nP3qE12KVDl+Nee2ItyPuMhplRdEqEXoidnoA4pOkfEb36cas8Ms8TdA0lCdv4tfo91UBQLBLPN53DNmmQ3MmKAJlW1ZF9kQCGYH6XyJNJRovPV9ZMEKvfdmCZeAAtrR6aSVC089ou++4mMbQb1u+nmnXctMyZ5vZbh5Yt9xfZWx2kF2Qfxw310O3OsQXGrlWzpC0g58GsQwgH4xtgGDZGgTS9+7WbHlW4hRH4ZHQPP8ScjnZPtim0w57J/j/Mewr5zKVwJYlNIcQJVoGeRK0XMvktY0WnKC0MlN8PbE8ytgNLYlUHpxJCw== 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 AM5PR0801MB1827.eurprd08.prod.outlook.com (2603:10a6:203:3c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Wed, 20 Apr 2022 06:59:41 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::1d77:d9e:16a8:75d5]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::1d77:d9e:16a8:75d5%7]) with mapi id 15.20.5164.025; Wed, 20 Apr 2022 06:59:41 +0000 Message-ID: Date: Wed, 20 Apr 2022 07:59:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH 04/12] Add an arm-tls feature which includes the tpidruro register from CP15. Content-Language: en-US To: John Baldwin , binutils@sourceware.org, gdb-patches@sourceware.org References: <20220323210048.25525-1-jhb@FreeBSD.org> <20220323210048.25525-5-jhb@FreeBSD.org> <31fefe5b-4fe5-3e3b-5eeb-b1328c584916@arm.com> <1a6aba25-a5a5-7ec6-7465-371aa3ca7072@arm.com> <49fd117d-6207-1335-5300-dcbbce05b29b@FreeBSD.org> From: Luis Machado In-Reply-To: <49fd117d-6207-1335-5300-dcbbce05b29b@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0486.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13a::11) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: b698f84d-98e7-4109-4339-08da229b5daa X-MS-TrafficTypeDiagnostic: AM5PR0801MB1827:EE_|DB5EUR03FT037:EE_|PR3PR08MB5770: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: kaNKmmrxSfj0XsuC1bUr5hLdthlUTvaCnhXV0sHPk3XD3bo3rCdBxIZoBb4wBr9M6FcZdYNtajxzoHG5sTZI4jpWkY/R6eBZNOUYDoX2JWYI4dT1/MKF/AzGmUF3yJY8HoolRsKsJG8fiHtKwOWySd3wXUBkDwPW6GD7gzSwdFY2/vaoFQ0ppvSFAAF0xbNsAlZcfTvMsmxJjT0qj0ydiuMqwkeetInrJwU90XB0hOxoL3jgpBX5p4u3UcJzf+YZjHA5ur8UbRAAk+nffAsEyiCiJMnvWTr76i4OJ7chJemXycwroFmbbPMdDcnXMd+gSyTUzVLPwckDHvA/GeMfhLR37eX8VurUHaI+KST38SOnN38z4nxYhxc8z2OKV1e/4oj3XzVLWs+KmHHBntGC8IQFusULeqjLhrpK5vEBPH33LSt9p68egTtasQoX6V+VRdIhYvy4ERiIxLG63TfbRQYAPAyUV4YgdHerDfKmUJcN/IPj31benjTxxmCVEp7ppDZs21276sCWm4wHjI1juAYPaiB6iEsOt40CYCH3pg2bA/ddMMHco5KMHQk16GRdKRE7HCFSo0QpLDfbvLawD8KY/lonUNk1fYvFUwO7tIMrt8z+ZDJa0H558Utg+fpTKvF7HZ7izB3/vVzsglI6CUpsQnRuFeOuka2MXRudOUnTyaYb3m/1D8zVvfPFOsjG1Da2Kq8pDd883aCLefGCpNLsQhIgiRPNLUAlwPHnc1s= 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)(83380400001)(53546011)(6512007)(31696002)(6506007)(86362001)(186003)(26005)(2616005)(38100700002)(8936002)(5660300002)(44832011)(8676002)(31686004)(66556008)(66946007)(66476007)(36756003)(2906002)(316002)(508600001)(6486002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1827 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: DB5EUR03FT037.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: fa218e0a-7b53-4b60-6917-08da229b57a4 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KaftK6V4EPgt/cZxagS8cAyU3iYzFHutKvB4+I3m0/eTXdOLDY7pUWOIRoInmIzmF1b35jqGDrMeMzXBSPy4b5Nvtu8Zbd9x76vBVMR2m6LVEat4q3WlVQjssEIMDLY2+FkoawyhbsOZkTZZj2d5C2fC0/bwr34dcWFu228TF+g5CjxzWlWhCtDqUu0qiwCuH2FBwJuBBq1A01uKa/3+EZWSioOzvfelr3j/FU1nTjE4acVOHZdKDUV5pm3Sbb1XHvk56yS8QPOA1+kaQAIvlk/Re8cYmaWIFKASr+gWCwFwqqwXmmwsI4tUs38CvNdVeeWSJ14hSTsiqrWgzhy8jGnKVEL979Prnr3cmG6L0KI5SjY+DayUt2NJKBtk+lIRPd1TPThgwlVEllkpSBHNC3KSLQuBSQaZN0eYVYjIzj7Db+eqbEOaqzpP1+4Y+4bBVU+zCdJnz2DBcpgU5CtUbP0BKoEFhxOImKgCWobBeF5iCLa13WAV+doQbqPOBZhXOxsiYrDf2sg9ldT352DGKgxirB8x2fG9e2TryRX/vYuaQg2S0oxcLHPeiA/CZwd49BwCJunaAKxvc13KFD51hAXEAfIehLcBML+PDFR1apwhZ84asoHKBXBoWh2bXv6/LanqBQN50/qjC0LNHET6RB6JCqR8zu4OQYyGhSvksLfDzQR/9OA43A2gwSmlsCvOkuFQvytMxmkUhqL9sWOabQ== 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)(36840700001)(40470700004)(46966006)(70586007)(5660300002)(83380400001)(82310400005)(86362001)(70206006)(53546011)(36756003)(44832011)(508600001)(450100002)(2616005)(186003)(6486002)(81166007)(2906002)(316002)(40460700003)(6506007)(47076005)(8676002)(26005)(336012)(356005)(6512007)(36860700001)(31686004)(31696002)(8936002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2022 06:59:51.3061 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b698f84d-98e7-4109-4339-08da229b5daa 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: DB5EUR03FT037.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR08MB5770 X-Spam-Status: No, score=-13.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Wed, 20 Apr 2022 06:59:57 -0000 On 4/19/22 17:18, John Baldwin wrote: > On 4/14/22 3:23 AM, Luis Machado wrote: >> On 4/13/22 00:36, John Baldwin wrote: >>> On 4/4/22 1:01 AM, Luis Machado wrote: >>>> Hi, >>>> >>>> On 3/23/22 21:00, John Baldwin wrote: >>>>> --- >>>>>     gdb/arch/aarch32.c           |  2 ++ >>>>>     gdb/arch/arm.c               |  6 +++++- >>>>>     gdb/arch/arm.h               |  7 ++++--- >>>>>     gdb/arm-fbsd-tdep.c          |  4 ++-- >>>>>     gdb/arm-linux-nat.c          |  6 +++--- >>>>>     gdb/arm-linux-tdep.c         |  4 ++-- >>>>>     gdb/arm-netbsd-nat.c         |  4 ++-- >>>>>     gdb/arm-tdep.c               | 20 +++++++++++++++----- >>>>>     gdb/arm-tdep.h               |  2 +- >>>>>     gdb/features/Makefile        |  1 + >>>>>     gdb/features/arm/arm-tls.c   | 14 ++++++++++++++ >>>>>     gdb/features/arm/arm-tls.xml | 11 +++++++++++ >>>>>     12 files changed, 62 insertions(+), 19 deletions(-) >>>>>     create mode 100644 gdb/features/arm/arm-tls.c >>>>>     create mode 100644 gdb/features/arm/arm-tls.xml >>>>> >>>>> diff --git a/gdb/arch/aarch32.c b/gdb/arch/aarch32.c >>>>> index 0c544d381f1..4d6ffb44a15 100644 >>>>> --- a/gdb/arch/aarch32.c >>>>> +++ b/gdb/arch/aarch32.c >>>>> @@ -19,6 +19,7 @@ >>>>>     #include "aarch32.h" >>>>>     #include "../features/arm/arm-core.c" >>>>> +#include "../features/arm/arm-tls.c" >>>>>     #include "../features/arm/arm-vfpv3.c" >>>>>     /* See aarch32.h.  */ >>>>> @@ -38,6 +39,7 @@ aarch32_create_target_description () >>>>>       /* Create a vfpv3 feature, then a blank NEON feature.  */ >>>>>       regnum = create_feature_arm_arm_vfpv3 (tdesc.get (), regnum); >>>>>       tdesc_create_feature (tdesc.get (), "org.gnu.gdb.arm.neon"); >>>>> +  regnum = create_feature_arm_arm_tls (tdesc.get (), regnum); >>>>>       return tdesc.release (); >>>>>     } >>>>> diff --git a/gdb/arch/arm.c b/gdb/arch/arm.c >>>>> index 126e46a950a..15b600e22f4 100644 >>>>> --- a/gdb/arch/arm.c >>>>> +++ b/gdb/arch/arm.c >>>>> @@ -22,6 +22,7 @@ >>>>>     #include "arm.h" >>>>>     #include "../features/arm/arm-core.c" >>>>> +#include "../features/arm/arm-tls.c" >>>>>     #include "../features/arm/arm-vfpv2.c" >>>>>     #include "../features/arm/arm-vfpv3.c" >>>>>     #include "../features/arm/xscale-iwmmxt.c" >>>>> @@ -373,7 +374,7 @@ shifted_reg_val (struct regcache *regcache, >>>>> unsigned long inst, >>>>>     /* See arch/arm.h.  */ >>>>>     target_desc * >>>>> -arm_create_target_description (arm_fp_type fp_type) >>>>> +arm_create_target_description (arm_fp_type fp_type, bool tls) >>>>>     { >>>>>       target_desc_up tdesc = allocate_target_description (); >>>>> @@ -409,6 +410,9 @@ arm_create_target_description (arm_fp_type >>>>> fp_type) >>>>>           error (_("Invalid Arm FP type: %d"), fp_type); >>>>>         } >>>>> +  if (tls) >>>>> +    regnum = create_feature_arm_arm_tls (tdesc.get (), regnum); >>>>> + >>>>>       return tdesc.release (); >>>>>     } >>>>> diff --git a/gdb/arch/arm.h b/gdb/arch/arm.h >>>>> index f75470e7572..32f29b20d33 100644 >>>>> --- a/gdb/arch/arm.h >>>>> +++ b/gdb/arch/arm.h >>>>> @@ -49,6 +49,7 @@ enum gdb_regnum { >>>>>       ARM_D0_REGNUM,        /* VFP double-precision registers.  */ >>>>>       ARM_D31_REGNUM = ARM_D0_REGNUM + 31, >>>>>       ARM_FPSCR_REGNUM, >>>>> +  ARM_TPIDRURO_REGNUM, >>>>>       /* Other useful registers.  */ >>>>>       ARM_FP_REGNUM = 11,        /* Frame register in ARM code, if >>>>> used.  */ >>>>> @@ -65,8 +66,8 @@ enum arm_register_counts { >>>>>       ARM_NUM_ARG_REGS = 4, >>>>>       /* Number of floating point argument registers.  */ >>>>>       ARM_NUM_FP_ARG_REGS = 4, >>>>> -  /* Number of registers (old, defined as ARM_FPSCR_REGNUM + 1.  */ >>>>> -  ARM_NUM_REGS = ARM_FPSCR_REGNUM + 1 >>>>> +  /* Number of registers (old, defined as ARM_TPIDRURO_REGNUM + >>>>> 1.  */ >>>>> +  ARM_NUM_REGS = ARM_TPIDRURO_REGNUM + 1 >>>>>     }; >>>> >>>> I'm attempting to move away from these hardcoded register numbers. If >>>> there are optional features, that means ARM_NUM_REGS won't reflect the >>>> reality anymore, and there may be holes in the register numbering. >>>> >>>> For example, a bare metal target may not have ARM_TPIDRURO_REGNUM. The >>>> correct way is to account for it dynamically, similar to what we do >>>> with >>>> MVE (and to what we do for pauth, MTE and your TLS handling). >>> >>> Note that these constants aren't required for the remote protocol >>> however as >>> GDB's remote target figures out its own mapping between remote register >>> numbers and the internal numbers used in target descriptions.  Having >>> fixed >>> values means one can use constant register_map_entry structures that can >>> be reused (e.g. I often reuse the structures from -fbsd-tdep.c >>> files >>> in the -fbsd-nat.c file to handle a register set in a native >>> target). >>> >>> Other arches work fine with holes in the register number space (e.g. >>> x86 uses fixed constants for various optional register sets like the >>> different sets of vector registers). >>> >> >> Indeed. It is true that these holes have no negative impact other than >> "maint print registers" showing empty entries and the number of >> registers being slightly misleading. >> >> The register_map_entry structures work nicely, but they don't provide a >> good way to track pseudo registers alongside the real feature registers. >> Having more clear boundaries between each feature and the registers and >> pseudo-registers in them looks cleaner to me. >> >> Some time ago I disentangled the handling of pseudo registers for 32-bit >> arm, as it started to get a bit chaotic. >> >> Most of the feature handling tends to happen in generic arm-tdep, so >> that only needs to change once. >> >> Unfortunately the linux and fbsd layers for 32-bit arm work in slightly >> different ways. Ideally they would share more code and we'd unify some >> register handling. But we're not there yet. > > So I'm not quite sure how to parse your reply in terms of would you rather > me make the TLS register numbers dynamic on both arm and aarch64 with a > field in the tdep structure holding the number, or fixed values as the V2 > patch series currently does?  Also, a question I have in the V2 series is > if NT_ARM_TLS is old enough to be present on all supported Linux aarch64 > kernels or if it needs some runtime checks to decide if the register is > present or not for a Linux kernel. > I'd rather have the dynamic register numbering in the generic files for now. In the future I'd like us to converge on a unified form of handling these as to avoid having the linux and fbsd files using different mechanisms for no good reason. As for NT_ARM_TLS, it's been in the Linux kernel since 2012: commit 478fcb2cdb2351dcfc3fb23f42d76f4436ee4149 Author: Will Deacon Date: Mon Mar 5 11:49:33 2012 +0000