From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70043.outbound.protection.outlook.com [40.107.7.43]) by sourceware.org (Postfix) with ESMTPS id 46FA33858C52; Mon, 4 Apr 2022 08:07:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 46FA33858C52 Received: from DU2PR04CA0207.eurprd04.prod.outlook.com (2603:10a6:10:28d::32) by AS8PR08MB6679.eurprd08.prod.outlook.com (2603:10a6:20b:393::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31; Mon, 4 Apr 2022 08:06:57 +0000 Received: from DB5EUR03FT034.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:28d:cafe::ea) by DU2PR04CA0207.outlook.office365.com (2603:10a6:10:28d::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31 via Frontend Transport; Mon, 4 Apr 2022 08:06:57 +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 DB5EUR03FT034.mail.protection.outlook.com (10.152.20.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.19 via Frontend Transport; Mon, 4 Apr 2022 08:06:57 +0000 Received: ("Tessian outbound 9511859e950a:v118"); Mon, 04 Apr 2022 08:06:57 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 3c412f481e4d3b95 X-CR-MTA-TID: 64aa7808 Received: from 2f1a30b4e581.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6DE344B7-B25C-4B16-9439-D17357D070B3.1; Mon, 04 Apr 2022 08:06:50 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 2f1a30b4e581.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 04 Apr 2022 08:06:50 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jWzwadkdI06dyR1/t7194gmc8HMDThQPGZ+3om+rHIPZWd2lngr8GAdgUht5bk7aEYDYJ6sFA02/ogZEBpqtKlAO2pMXFM2LiQwgbO8x56FeFq9oW4S1iV3LfUPlJRp9IAPIBQAN1hyeuDlvwcx6ytJ05hgs0bkBz7bL9dphcnLqkDPfJ4IrRp3kdXkjdOmPfp0dC6iDdd2LTW5VSrnR1hDSBKK+NYLxzCa81XSrgyOT6xjcYkM8UXwJk2yQrdWIhvgg47C7LYMyUIW1jzDUwIDnn7MmgyJ6AVNZEn3A9/pTCbaY8J+2/s/U2ggL16fzNpklY9g1/kg+vGgOAjwqdg== 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=WpjIJuOMXQcM3Sgf6L+JKoO7Yo9JQWowpme1194p/OU=; b=XgJuTf1RSRRiWzElLDRV3GHSHOsfGb2SC40NTFMooRrrMNddNdsgGu0TkxCOZuqI2aBs/zcZlwVUKZvNmJZEcfP5FX+GTJ8Lc04izThXjuPEwEdTFlLOa+xCFJ5BpmQ8KWFDPH0qH6gYZ+h7/5eIN2oyWrlCGsvAolFXEtjFtxL1qMQRBBZchluh3GqRDUOSqCL8lbgrqOS/4Q1mgtKN0r5uEKIomGS02e1bSOXUqB3LANW7akiCpGRdu/TaNjem2QHR0OG8KyxTM1djdePhGFOb47KbGixSSWZh6wx8e2c+km+00f49dWGXFczr+9CGdLbXCaa4l482lyJaT6hC4w== 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 DB6PR0801MB1880.eurprd08.prod.outlook.com (2603:10a6:4:74::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31; Mon, 4 Apr 2022 08:06:47 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::905f:29ee:d858:516e]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::905f:29ee:d858:516e%7]) with mapi id 15.20.5123.031; Mon, 4 Apr 2022 08:06:47 +0000 Message-ID: <7fd1bcc5-ce8b-df79-d64d-b7e7e5fc6a7e@arm.com> Date: Mon, 4 Apr 2022 09:06:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH 08/12] Add an aarch64-tls feature which includes the tpidr register. Content-Language: en-US To: John Baldwin , binutils@sourceware.org, gdb-patches@sourceware.org References: <20220323210048.25525-1-jhb@FreeBSD.org> <20220323210048.25525-9-jhb@FreeBSD.org> From: Luis Machado In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0249.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a7::20) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 095d6388-685c-4ed9-4ec2-08da161216d0 X-MS-TrafficTypeDiagnostic: DB6PR0801MB1880:EE_|DB5EUR03FT034:EE_|AS8PR08MB6679: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: 0TaBN8EjvWVSlGXnE9uF3oWeSHKMK4z8Brrb11e4Fg7RA5rwCMwOfsNnmvoD+zs/5Xi2+Ax4Fmzwz4ofKsHvJTbExwQpj87HKnAodlLvqa36RgKG9JoQ0swgKsqoGdkG5usYchE6zXxldlo8aTeXbc+7pg4cNIIh/LkR2ELJ0mVKZfrW9inQPagIeqoiIVLjC0by+btiwQf+EIUxvcj2WggAoMhK04MQlBj5Vk4AXtuUqbVjbARgNSp5blBJee5QjUniCHvg0UDGvaqX2qtD7F96+KmzPy0z2GL6Ljbc89y+GJZP4yRD+XwVTy2zoYKl+9q6IJFGC4c+LsJaxSu2JFD1PrcRFz0vX+bsMW7b24hvnpwi3LnK0vgbHwdoSTVfU/VXFUsorBivo10ZUHjFb8Ky6/xcUYBf4boWL7vJtRDT0WlQvJcAyzNPgcO0tL+4fzj6REHr3sCO9ldyQ1kUwLdrrsHYygKs0BpIfuPzh/DzwPyPhPjEW3loGghHktS7mf3vd7GJ8rVSUxlBOpjLGsvTRYwDsLawIrE3u9epfHf80MjTrQlaxOpZLI0eAbz0EbjccUptvP30AG8PQvRUWHHc+8aBd/0dIzP0QSM8Fkm7MG3H59ooGmutnA/nBL5N5GM7ZQXXEeJNrBqTEK641+eAASajYdS7OmdjWv0mdYJUIfNcQluNNWy954PCXC5jvOfwXo9wwjRIU/M9TAiYxc46DdZC56JHfjlhIA4GP7A= 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)(2616005)(6666004)(38100700002)(508600001)(31696002)(5660300002)(83380400001)(86362001)(36756003)(6486002)(8936002)(31686004)(6506007)(53546011)(2906002)(316002)(6512007)(26005)(44832011)(186003)(66476007)(8676002)(66556008)(66946007)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1880 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: DB5EUR03FT034.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 934aad4d-2bf6-4a38-f396-08da1612108c X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sFLeT1fmLXISyrMwLXDAydzW4A3cDRPwHv4S04zVxMD6SR68ueHqyaa3cwOQi0V4aCkSfYwyqYO7UxZVz6gZrOcaqA1ceXYQNo8MHoePNXr/QgOxwDcr7ISnSR0JCmyZX1ZU1k4+/Y6v1X8EV58HSYJrXyv5rBTKB1/pDCBiDv1Cemo8I3n8Pm1fg+xcOf4VfTlhp/cLJRBS8wRAnBqc08Lsl0Y2p/lo6q/phH+Tc3V4oPnTnvEzGY6uV7pWhpRX+UICkariCuEPnhoIjI4gMIad+cKggLmzpMVVau1YDGxyqAs0G/9n58fPtapZbc2MUlX3OpTLWc9BJT3w5ygty4izjljJO86MtY0/1RFbAnhrzuatCWo4hyrUSPSVhdY+2ATBlgWTXaJp+IfkpaE+GFh9f/zDIKyoSiQz26y3Y5zopRVnpluibYSUqAJhoG97CfEi/Bm5yL1pXO3/xzQb3xIx9hj3tOxgmBaREelylVeRxRsfLXO74d3ZAIl5WOC1slFQNdhRnwtC4w3S34TtB6PGmqJHkX6O48GbDoR9VcqE68mcFelNBVs/9R1QHIVvaiWBmZZPXbu2yUcoc7uO/SP48iEaOhYn+VZrscm+iiTZoYkcFFEYKZnvQPNPnx0kYXN7c09cakkOGoCbIBom0uMTnwjF1YfJI4AAh5c12/NtrJ/ElNNvA40kFP6rYRekE1f5OJQdJ/Tk6/H3jTPzKA== 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)(46966006)(36840700001)(40470700004)(450100002)(70206006)(70586007)(6506007)(6512007)(316002)(6486002)(36860700001)(6666004)(82310400004)(508600001)(86362001)(31696002)(40460700003)(83380400001)(53546011)(47076005)(356005)(31686004)(2616005)(336012)(81166007)(186003)(26005)(8676002)(8936002)(5660300002)(36756003)(2906002)(44832011)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2022 08:06:57.4179 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 095d6388-685c-4ed9-4ec2-08da161216d0 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: DB5EUR03FT034.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6679 X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, NICE_REPLY_A, 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: Mon, 04 Apr 2022 08:07:03 -0000 On 4/2/22 00:30, John Baldwin wrote: > On 3/28/22 3:16 AM, Luis Machado wrote: >>> -  return aarch64_read_description (aarch64_sve_get_vq (tid), >>> pauth_p, mte_p); >>> +  return aarch64_read_description (aarch64_sve_get_vq (tid), >>> pauth_p, mte_p, >>> +                   false); >> >> This is getting a bit ugly. We should pass a single struct that contains >> all available features eventually. But it should be OK right now. > > Mmm, a struct would be nice, yes.  Maybe I will do that as a followup > change. My idea is to have a shared struct between gdb and gdbserver. Then do feature checks based on that. I did do some of that for gdbserver, but it didn't make its way to gdb yet unfortunately. > >>> diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c >>> index b714f6194b6..38c5c9e0e00 100644 >>> --- a/gdb/aarch64-tdep.c >>> +++ b/gdb/aarch64-tdep.c >>> @@ -3555,6 +3565,21 @@ aarch64_gdbarch_init (struct gdbarch_info >>> info, struct gdbarch_list *arches) >>>          num_regs += i; >>>        } >>> +  /* Add the TLS register.  */ >>> +  if (feature_tls != nullptr) >>> +    { >>> +      first_tls_regnum = num_regs; >>> + >>> +      /* Validate the descriptor provides the mandatory MTE >>> registers and >>> +     allocate their numbers.  */ >> >> It should say TLS instead of MTE. And also adjust it to mention it is a >> single register (at least for now?). > > Oops, did miss a MTE rename.  Note that the MTE register set also > contains a > single register but still uses the plural (but I will fix this).  If you > think > it's clearer I could remove the aarch64_tls_register_names and just call > tdesc_numbered_register() once without the loop with the specific > register name. > Probably copy/pasting. I think it should be fine the way it is then, for the sake of keeping it consistent. >>> +      for (i = 0; i < ARRAY_SIZE (aarch64_tls_register_names); i++) >>> +    valid_p &= tdesc_numbered_register (feature_tls, tdesc_data.get (), >>> +                        first_tls_regnum + i, >>> +                        aarch64_tls_register_names[i]); >>> + >>> +      num_regs += i; >>> +    } >>> + >>>      if (!valid_p) >>>        return nullptr; >> >> We should probably error/warn loudly about the fact this feature lacks a >> mandatory register. > > It requires the single "tpidr" register I think? > Right. Is your intent to make tpidr a mandatory register for FreeBSD going forward? So if it is missing, should it be considered an error? For Linux it shouldn't make the feature selection fail, for example. >>> diff --git a/gdb/arch/aarch64.h b/gdb/arch/aarch64.h >>> index e416e346e9a..79821666ce6 100644 >>> --- a/gdb/arch/aarch64.h >>> +++ b/gdb/arch/aarch64.h >>> @@ -29,6 +29,7 @@ struct aarch64_features >>>      bool sve = false; >>>      bool pauth = false; >>>      bool mte = false; >>> +  bool tls = false; >>>    }; >> >> The tls field doesn't seem to be set/used anywhere. I think it should be >> set when we find the tls feature, and used during gdbserver linux/bsd >> target description selection. > > Mm, yes.  Arguably this structure should be the thing that replaces the > parameters passed to aarch64_read_description(), though I think it would > need the vq value and not just a bool for sve to serve that purpose. > That's true. >> Also, the patch adjusts the gdb/aarch64-linux-nat.c file, but doesn't >> touch similar code in gdbserver's gdbserver/linux-aarch64-low.cc. We >> also support NT_ARM_TLS there, but we don't export this particular >> register through a feature. > > So for this particular patch, I'm just trying to add the arch feature > itself.  The later patches in the series (some of which don't seem to > have made it to the mailing list actually, so I will resend), make use > of it in aarch64-fbsd-tdep.c and aarch64-fbsd-nat.c.  The changes to > aarch64-linux-nat.c in this patch is just to support the new argument > to aarch64_read_description(). > >> I think it makes sense to do so, though I understand that is outside the >> boundary of bsd work. Let me know if you'd like me to enable that and >> test before the patch goes in. > > I can probably take a stab at this based on the FreeBSD patches in the > series (they should be fairly similar, at least for the tdep.c file). I have to teach binutils about this particular register set (NT_ARM_TLS). I see readelf currently doesn't recognize the proper name in a core dump. I'll send a patch soon. >>>    /* Create the aarch64 target description.  A non zero VQ value >>> indicates both >>> @@ -36,10 +37,12 @@ struct aarch64_features >>>       an SVE Z register.  HAS_PAUTH_P indicates the presence of the >>> PAUTH >>>       feature. >>> -   MTE_P indicates the presence of the Memory Tagging Extension >>> feature.  */ >>> +   MTE_P indicates the presence of the Memory Tagging Extension >>> feature. >>> + >>> +   TLS_P indicates the presence of the Thread Local Storage >>> feature.  */ >>>    target_desc *aarch64_create_target_description (uint64_t vq, bool >>> has_pauth_p, >>> -                        bool mte_p); >>> +                        bool mte_p, bool tls_p); >>>    /* Register numbers of various important registers. >>>       Note that on SVE, the Z registers reuse the V register numbers >>> and the V >>> @@ -84,6 +87,8 @@ enum aarch64_regnum >>>    #define AARCH64_PAUTH_CMASK_REGNUM(pauth_reg_base) (pauth_reg_base >>> + 1) >>>    #define AARCH64_PAUTH_REGS_SIZE (16) >>> +#define    AARCH64_TPIDR_REGNUM(tls_reg_base) (tls_reg_base) >>> + >> >> The purpose of similar macros is to index a register given a base >> number. Given the TLS set is just a single register, I don't think this >> macro should exist. We should use the value recorded in the tdep struct >> instead. > > Ok, I was just following what had been done for MTE.  I'm fine with just > making it a single value.  Alternatively, it might be nice to allocate a > fixed value for the register in enum aarch64_regnum.  I only picked a > variable base due to copying what was done for the PAUTH registers.  If > adding a new AARCH64_TPIDR_REGNUM after AARCH64_SVE_VG_REGNUM is ok, it > would be simpler (e.g. I could use a static regcache_map instead of having > to construct one dynamically). Right. The idea of recording things in the tdep struct is to better organize the register sets in the presence of optional features. You might have some of the features, but not others, and we can't leave a hole in the register numbering. At the moment there is a mix of macros and structs. My plan is to eventually convert everything to a single mechanism. A regcache_map might work nicely. > >> Also, I couldn't find any uses of AARCH64_TPIDR_REGNUM. Maybe I missed a >> patch? > > It is used in one of the FreeBSD patches that didn't make it to the list > (but was included in the cover letter). > Ah, I see.