From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) by sourceware.org (Postfix) with ESMTPS id 87E993858D28; Tue, 12 Apr 2022 23:36:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 87E993858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id DD85881299; Tue, 12 Apr 2022 23:36:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdMYF5fkqz3pWK; Tue, 12 Apr 2022 23:36:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649806561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7No/WumchdU3Scg//NV/83UdkRe9ml3QlPuxKmwRqPk=; b=NZMKBHD/79X6FIzrvqYVMlpYp8yX6JQbw4jlhJ8ACwrhcF5/fCmGrIw6mwIweZb1AaWJSi GUbi3OH9BqY8+Rxgd4r9XwLPeJptRWQDsE5GgO0U3f7EL0z68IrPh2uSlw6hl+J/Jn0Slz 75soPZ0ZtbQCIz++wnBzIv8lfOTpNc2RgB8yvpoHM3pfTdAOcqOizN7pwlYWC3Yo89YkVT xRnFheTUB9k/KU5VNfO1fLURTrzM1j63YYjWrS32lm84sjVQsGr7mAc3iuKuqoUQr4Rjq3 IFgK5yMMM15zw+aWe4Co806EG/DstdpQAH9BHF+PfpahMk+ZHWgSJm7YRuPsDA== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 289B92414A; Tue, 12 Apr 2022 23:36:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 12 Apr 2022 16:36:00 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; 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: Luis Machado , 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> From: John Baldwin In-Reply-To: <31fefe5b-4fe5-3e3b-5eeb-b1328c584916@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649806561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7No/WumchdU3Scg//NV/83UdkRe9ml3QlPuxKmwRqPk=; b=FKtOUgyJaZywDE1DfmYSfZWMh+kJDtPbfAMoeSODE1UuzbbstJiqVv2P9a+AoACf6ewhIq +1vtGkKji8VwhrF5vl94C6IBYDV9zEJ8MQ3yErQMU5td6ZQxD6XZhO+UsHD1enwI7h9fge 5ORAovLt4KNDfwAo/cOZy1PxE1bi+Subm0nxWgxn5h8plampw10jzkwyZx1UZi6ayE4x7x QfIV6QK7xbHhE5BZMlrlw1ic7IlSlKco0o4GVxXy9fv+l14UGXjf+ua5vSpORQi2ndwtCl MH0k9jPW0wxRN9ZfsA/EU47Yt+BhRIRL8RtMmICtp8+W7aovdYiu1vbtaf/tzQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649806561; a=rsa-sha256; cv=none; b=RY53Z66wPmfM7dOgOsOWoEGy6hyxdfynJaEOpJI8zAsiocZfKeWJuZYy74pnPqsDGpnBWq 0js8FBcMfysHpJThfi58muBwPh43KWEN+9/H6G9pZDm4PWt2RSHRHXJe4RzpbyTmldOnqs u8lXt96yapZZumRdBxxHL+5aD3cxoJlwZ+tg5M9EzTiibmDea/oFxGR2EIaxcEgGFlSEdi 45KIlFAgbtynTTPIpPuE4fAa/Lup97x3rpzVwLx3oh1tnkmjHXrjrzihllifPW2HL1AgRg s83myTR2tEDVhN4mJwNpgyxflv9Z9+uDWnZQPLTjSRwYeBsOAxGtyazbcBF+Rg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: Tue, 12 Apr 2022 23:36:09 -0000 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). -- John Baldwin