From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60061.outbound.protection.outlook.com [40.107.6.61]) by sourceware.org (Postfix) with ESMTPS id AE1813858D1E; Mon, 4 Apr 2022 12:18:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AE1813858D1E Received: from AM6P195CA0039.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::16) by AM0PR08MB4467.eurprd08.prod.outlook.com (2603:10a6:208:138::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 12:18:50 +0000 Received: from VE1EUR03FT023.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:87:cafe::76) by AM6P195CA0039.outlook.office365.com (2603:10a6:209:87::16) 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 12:18:50 +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 VE1EUR03FT023.mail.protection.outlook.com (10.152.18.133) 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 12:18:50 +0000 Received: ("Tessian outbound facaf1373bbd:v118"); Mon, 04 Apr 2022 12:18:49 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 500a7f4a412b3eb5 X-CR-MTA-TID: 64aa7808 Received: from ab30a1a4f225.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 2897E5B7-1862-425D-9456-0C24715660C2.1; Mon, 04 Apr 2022 12:18:43 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ab30a1a4f225.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 04 Apr 2022 12:18:43 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SFUpMRLSrw0lqEfCJuaSrqN111ilKQbO5IFJgW3S1yZF7qmZYU06uHodtqdcjZ1Ev5bbELGRr+J1PjfuhoSRIaAB6tptQq4RRFkaqRj6t97ihs6Y+S9K6z4KchvleDojbafolCqttgFYmalGk3VppIBONrnAPzvGMC4SJYpHixkCFUJ0+FtGNOyVZmxPQm0V1Q/2dR6CoIJowKX21Lwfar/5XrbrH7TM706vpKS+Fdf+5MWGktE8WlUlYtviulA0b2s1HZpMCm+RYp6ZHIuFzuj2Kf+Xa8umgucqXCnToVofq0xa23tcb2vVeSg+A2TOSlAEQjt3ybZ2Rlk3+Gew4w== 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=rRrIeqIOpD69+iVG72pVaYxb+91onQXgnC1RtXC+oWQ=; b=UqUspLrU+/+4FjjL+4ZQgZ9txd6pPYmsh7PhwBmnbC+8vrV2yyHBdVPh3ieO1B1fwfWqiYtTpUfZkdgFCK6EucUTDJGL7VBFq9OFpp5uHX1kQufoz+GUEC342pzGf7fFytggwdlKkMfDD6JprjZgjBNcxe0De4GYy60Xb5cIA9vNrgtSzGqKLZyHF0/ppYMnWcLPXfn0qgJtLNiDZ0tDiozBUztVbo8Fe6frYN/BTgzb2RohyX1rDkPmSnY0WLpcsmaCvjPrxqu7sRVJRfjcpcLMMEdme7Y+pnF2lae5ZCIgnMF38n9QAFvUVfmFr4mfNVlVAET8OQgPwuIr6GHXGA== 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 VE1PR08MB5597.eurprd08.prod.outlook.com (2603:10a6:800:1b3::9) 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 12:18:37 +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 12:18:37 +0000 Message-ID: <5c6b4d87-4134-7714-43c1-ddadd1409678@arm.com> Date: Mon, 4 Apr 2022 13:18:30 +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 From: Luis Machado To: John Baldwin , binutils@sourceware.org, gdb-patches@sourceware.org References: <20220323210048.25525-1-jhb@FreeBSD.org> <20220323210048.25525-9-jhb@FreeBSD.org> <7fd1bcc5-ce8b-df79-d64d-b7e7e5fc6a7e@arm.com> In-Reply-To: <7fd1bcc5-ce8b-df79-d64d-b7e7e5fc6a7e@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DM5PR07CA0114.namprd07.prod.outlook.com (2603:10b6:4:ae::43) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 4fd3c2a6-7254-486d-a548-08da163546da X-MS-TrafficTypeDiagnostic: VE1PR08MB5597:EE_|VE1EUR03FT023:EE_|AM0PR08MB4467: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: RCHBUZtYc9ZX8ceOuKzjNEc+71FZFyi/jo08pbvKgyc5Nduuuh68B0sbDvFVM5i1m1Wfl25AB5V+edCmv1lDbr21SsfdgLvn9elnU2sJd8QbR343Ekn5/36i+FSaWzuEKoNSO0iQluZ327PdI9cLZU811wsw4zHZRL5MSN0lgBisZKPWC8mA4jEDpARVuQJw/+H+ruTrhkGEt7Q4zKrTf0OKI48HCGXgwj9DAeIfQGtfPaiI4Sz1Tzn2pcdJbhjrq8TsGgQY0NfzYnLnIC7iHzd5DsS9eLeu6wrgd50JRutXlotN4uBJYeOcSqzVtZvt932/WP9pSQBgsyuVZ4Wmr7dWAiBXiOkMRs1PX0PQHXBhBhuO0idszuT5olM+urfP6STSdX2NiBZDPTXMetpSrrhAOzHgo8d41DRshDQWS1gBy3JCek0Fbt7UJVw4ajqf9xbYN0mgfiwc542QHqrpR86ZAhYPpoV7E7pqjMEkvxlekSY2qsu/Mwq7edlxj+Qa22HBqPIArJxnvbrgzSGKsRbZZruAeU2MT5UC5UBVBuvV3iD/VjB/DTqFpjrzoI2RxJzGq/62v4/gm4d6JdyqpNKx0XFOz3ufl8r4FVTCIFT36dxPkQcEqVIN0k6Os3VDVO/6kWzXyf5yFhJXtOv7LqyjMMtTSug+/BAr6LDAuwtqmO8FuomC6hG4oJ+Mels0eGW8hBgve6YeKFPRx6fxWson35RNaNGGw2aD5GyiCUA= 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)(66946007)(66556008)(8676002)(6512007)(8936002)(31696002)(66476007)(53546011)(6506007)(44832011)(5660300002)(6666004)(38100700002)(86362001)(316002)(6486002)(83380400001)(508600001)(36756003)(26005)(186003)(2616005)(2906002)(31686004)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5597 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: VE1EUR03FT023.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: abab6682-f086-452c-8f54-08da16353e73 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NKlCdT4QII/XvX8QqQ8OGT3REit7mFTXn4vtn2JCOfo7zitnyp+s3BFY7KEhyE3QcjtmFLMImFhTqQSZdQ+Cf7c64AwjLNlFvM+EFAqu/SJVXZGAfCOYqpMKJFbxwHDqfnDVREyoHgDiLdbCTcUNtheesNupP5IVTpLQRo9iIUVOudLhz2Q+NkncVjhf9/3DkYkUtzWwBdJFZOdkO8SuMjIUNpPFi3U8zzDjne/ORxX+IqplJSBriiLxuf76NACLd/GI4Ep/j4tzHLoKsXbVGzHfheiu4WDMr7UAsYFtTwK7iHBBv1GgiJ2EJDHH/Q8/8uqic2pd5VbtNQWOrVJHkANzztle3eTM6y6PSSjG9J7KnBW9EtdD31rcVkYxHQMcj2eKp4LxbTG0/OKAu5Jf64lvhBqQUhrQz65PtGhzHdjygQSLkm/REebSJ3T9PZiYJaguRUOwGPHDTJY5Sh6Z/1trxMTDntoFxt58GyhtT8ZhjeCxGaJuFS7vCkfypPgU8AVlm97TaSZLgneBOJ+YPIi+SYg/gW3Tg1ptZQ2EYtdSBB5q2rdI0WkFb5s3EaZtPZ76xJFu9+ED/5iufQ4PCEfzGk2JP2IfCwy+F+rlBLhN3Hv7DyVK7uHQonjJCUNOaEZFBqYub152G0KIpFFxqFK4A/vg+268kDyIr/fzAgiVmOL/jmDc6MkGVTIyAHmkzwe8+b4BE70U5DVi55sE/A== 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)(40470700004)(36840700001)(508600001)(47076005)(2906002)(8676002)(40460700003)(70586007)(70206006)(83380400001)(6486002)(2616005)(6512007)(6506007)(450100002)(36860700001)(82310400004)(53546011)(186003)(26005)(336012)(36756003)(31696002)(6666004)(5660300002)(356005)(86362001)(44832011)(316002)(31686004)(81166007)(8936002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2022 12:18:50.2752 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4fd3c2a6-7254-486d-a548-08da163546da 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: VE1EUR03FT023.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4467 X-Spam-Status: No, score=-12.0 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 12:18:57 -0000 On 4/4/22 09:06, Luis Machado wrote: > 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. > Sorry, scratch that. The set that isn't handled is the system call number.