From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id 721EE3858C83; Tue, 19 Apr 2022 16:18:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 721EE3858C83 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 [IPv6:2610:1c1:1:606c::19:1]) (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 2FF3B75FDB; Tue, 19 Apr 2022 16:18:26 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4KjTW60YMWz3QjG; Tue, 19 Apr 2022 16:18:26 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650385106; 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=a3si+LflzTaxxjAqt6yC5muCM1adXvRZf9bXb9S83GQ=; b=OHc0l4gVm1kGuwNgKuO1vZIznyPfHcEORr5+vLybQEEcueb9TRckbl36y/rw0LTtB3iSvi TFOAR1qesXRBZ6ODnQCtp9xnQ3o+qUcQNZqscEMS+D/NWX/+2DhDVCsGT22vN+p5vce+Ww ChOBLrg0dhjtgeujmWxG8xje4h7C4G2kc2hf4FNylalFItL/bdvUe/xsPAlMbKj3Ms2Lda RQzGnixTOGACj+YVMVfA7ayd5WL52jqbZnSZolDCubgHydk2elI5Pfd42811KZADImXdEt EpwciYcLC2aVSG4BY5sqf96SPTjI5u1fxSkWVfv6dXQGdM/lmjXB6i1l1EZKMQ== 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 779DEAC18; Tue, 19 Apr 2022 16:18:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <49fd117d-6207-1335-5300-dcbbce05b29b@FreeBSD.org> Date: Tue, 19 Apr 2022 09:18:24 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.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> <1a6aba25-a5a5-7ec6-7465-371aa3ca7072@arm.com> From: John Baldwin In-Reply-To: <1a6aba25-a5a5-7ec6-7465-371aa3ca7072@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650385106; 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=a3si+LflzTaxxjAqt6yC5muCM1adXvRZf9bXb9S83GQ=; b=bhr5cJSlaIvTc7T91K0XobYsSDZUFpXF6z/o2UzleUmcgMf6m4bTRkVyRcHPp+X0gckIrF vbGVQAr/81PLzmdgpGuq+KQWhNKq4oSullSaerY4ZFDxbQMiHdEHMk8wFiVdRb3muumkfo 7oblANJF+jm4m4h8pHFSRMec4dAZ8Vj+NfvsxvqUt3ja3n48rzv01GYWTRVIgIIrOTB7IG U1BHwQqKWZf1QzZzpaRYRXgJLvwveBKc6/4BevGKIrgMwZFSBiD55r4N8jyaWXY6IZg4jr o6b62rlretQDehdOnvJg11KSjHMYWO1bR2fNrk5q2ahdXbe5wynWQ/ci7utayg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650385106; a=rsa-sha256; cv=none; b=yg0FGGXW4ZPuQftdM9Z86bjWUSFFnBiOKhq6dvFzUrzDbtwkvCw7auguqZ8qnnoU1hmiJB bHrM0TGzyh8NyMKFugjmC9gA2RWZvoyWjQxg/yEkj474ezMTHwmhAaMYsXWXy+/NRi8bWD DwdjLzoYZ5OHakvr2BmPS7NRCQ6o0R3YTShKxQ79m0u9AqiFY1S8WU/sv94TZedid6RFJa duStIowUnHBoj06QesoBuSJbEKaexlEViKYC2jNHV8jpVwYVgrZhRaWPn3hGFGGqUK3Po6 vHcpPSBIjNl45Is9e43J3VYCn/jFgxMrjungfjMBjPq7YDL6hYo+8V3tZS4KAA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2022 16:18:28 -0000 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. -- John Baldwin