From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2083.outbound.protection.outlook.com [40.107.20.83]) by sourceware.org (Postfix) with ESMTPS id 9A48B3858D32 for ; Thu, 1 Dec 2022 08:32:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9A48B3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k3btxfLF4GnFIc+1FB/QrUTUNkz7/45ABdAI9nM1FkChRM59vy9pTGXFsVGGjNzQflyf6c7tT0D9bqS30XnDFc36kTbICj4YbxPspA10fmrYfjNTX64lrdOHLDvWTTRZEnyQkdUjYc1b1Ti5yvbGzreaxUmpQQa7qzELD/rEe95HLaIpBERSzsirVzujsnOiTKndoZY+3FC0EYEQC4byDXq1rEPvrGYJJWg9qyW4A2AZu+cuZb//GkEyRh6clui4fGTnnbr/TBXx1flPVQPo3RFkSrnCqT5BxMO0Gm1g5Az+EzVirgzhsokAgysg735e4B8p9f2yiM/VvtbXifjLpg== 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=jh5rSzYUJly9ZiTaWjjOwFRvFdQVea9N9zVFyXjA5FU=; b=UevnxJrRF/cQj6azvu3zE+DUJaeMcL7DZRmhwcCIGChUuM83IWm9KZgwg/MO8LAmweXC+jlZxV8g40qvAPlBe5QbB7r6+CqLL0NwS+rQXJtNabhZ1Gic+RTuvuwI+TULU/SaX8nLp3pas2Uxg7Q5aWAQYSn3ptF6An11UVQ4nHS4/1N618Br8SlDbgUlaifreS0xTHTr8p9mhn4MepIpSsXgRPfl4LSTpp44hcVKM67ee/CGFH0yL21O8rvFtyhJ49j5mXeZJcn+1ZVPspm5QOs9bMWBI1T7kYDMJ9sPF4TYM/+fyz7Km4NJhTkiBbYFOJd3eqJe2ffIPahKilzZAg== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jh5rSzYUJly9ZiTaWjjOwFRvFdQVea9N9zVFyXjA5FU=; b=ZDaUi8b7b36Q3RfVEsR7Ky2PaWhFCkVrJWaQJLAoqjim7O5untWuS+VW9/Ii4Es6W85RVXGs65dN4FnvTMhzaDxSZbz3uMK8bkIUs7AUVyObbvQ4OG6Jd1LC3bpgEvKlOji3dTFxutFN5Tpfn/SjihLnVPR8zJrTdrzgxHcu9vA= Authentication-Results: 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 AS8PR08MB7718.eurprd08.prod.outlook.com (2603:10a6:20b:50a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.8; Thu, 1 Dec 2022 08:32:23 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::fe5c:b195:a2ad:b19c]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::fe5c:b195:a2ad:b19c%4]) with mapi id 15.20.5880.008; Thu, 1 Dec 2022 08:32:22 +0000 Message-ID: <7924fd9d-edc1-b0dd-4cbc-07026fd9f1c5@arm.com> Date: Thu, 1 Dec 2022 08:32:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH v2 6/6] gdb/aarch64: Detect vector length changes when debugging remotely Content-Language: en-US To: Thiago Jung Bauermann , Simon Marchi Cc: gdb-patches@sourceware.org References: <20221126020452.1686509-1-thiago.bauermann@linaro.org> <20221126020452.1686509-7-thiago.bauermann@linaro.org> <5d3ca3ed-df52-444e-1652-99b149137707@simark.ca> <87r0xjg6e4.fsf@linaro.org> From: Luis Machado In-Reply-To: <87r0xjg6e4.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SA9PR13CA0040.namprd13.prod.outlook.com (2603:10b6:806:22::15) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|AS8PR08MB7718:EE_ X-MS-Office365-Filtering-Correlation-Id: 3ef6b043-0c3a-4b3f-2ee5-08dad376912c NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bwSq3T5wY9Z4RNb4hMMOBA9GyUDPeLiXuDpSIYuXF3tj+DfwOT2nzDb64y58Upw8iLcr7lKUGEcFh9BNt5jD7brjRuP+KmKpleC8npc3BC3NsDpMh0UkZ/NmMy4/kNqBWHdT+3kqinNAH8FCXyFb+hq9MrtJLjiCoeBZ1ZS7bIu+iGueVfX16tqjUKLdmUe0kMyqeDNg1fbB0/1KfpQsTcG9V88/9FbBIVj/xHyiYgo1a+DzW7BBi8nymKzK4YUF+9teldkC0pdZ5B81fyFvF4SemrQ4aRnNTkIcIBs46azDCTUpLQLYNikym4Cjf0Sowes6PVA7KRwRUd2qtNIdl/AX77SKnOaGSSrA+sM8rJHw1xIaso65xbtuwDqYf0rGuTGoM+DaQcAa12So47dxfYaiuNPjnkeEJuNRm68ReoFxvqzFlmvYtpq1C2B1UBJlwLeqSPobqdwTUinod/C/pfMoLKoI9rJEcJ3Nnd54NlOr/LtwyKSBX/guCx+QS27ETDvlBF0lW0bRS6MdQe5syviYdhEjHrBRQTNPIlj9eGPl6EpIuvZhDSV2MCXNHG/aY/LwiAmVN/sjTgawwPa9EU0eu23I/v0rCVbrLFyszTT4cPomiXbGrGWF2rWp8ghgP4T+LQ0m97IkQV0D9SPQACOa+Tzv3TnwMB4drNWv+i6qT6hNtfXjXMf4LU5FjZVHN1kg56rN5j9qvjz6HlLY1SzLIcbi+pzJZ+5TtYAjYjo= X-Forefront-Antispam-Report: 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:(13230022)(4636009)(346002)(396003)(39860400002)(376002)(366004)(136003)(451199015)(66556008)(4326008)(66476007)(8676002)(2906002)(316002)(66946007)(110136005)(26005)(36756003)(6512007)(86362001)(44832011)(31696002)(83380400001)(186003)(41300700001)(8936002)(53546011)(38100700002)(5660300002)(2616005)(6666004)(478600001)(31686004)(6506007)(6486002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TVAwY21NRFhPTHNDRW9pN0YwaHZ6cEh6dnBkYU5OVm1jRlR4bjM1K29WSVJ6?= =?utf-8?B?OEhmQUg1U1N0SmRtcEpvVG0yQVBGdjlHcWRTb0J5WjY0Q2FiSzBwRWRUZHIv?= =?utf-8?B?SHV5YVdjeWVlVjFWWEFOR3NoRmJ0MEZwUHRvL3pNQUxkeDdoMWZxaFpqTUx0?= =?utf-8?B?R2xpa25Kc0FCekF3VFJKVExyYklwV1BVMG1aMHY4NEtvWGhnMWRoZWNZbDRs?= =?utf-8?B?UGl5K2tOODJlWExoNUM0VktmY1lZM0JFcmtQZTdzajhRTThVUGxRMDFXZlFz?= =?utf-8?B?V3BmakFMcWJhc1RNUVUrUlRZK20vZ1RJa1RQa0ZqTXEvZFU2UHdGMDV4QkhZ?= =?utf-8?B?QTNXNkdMZlhMeEMxSGJQK0NFQ3hROVBJMGE5endMZTV6RXUwZUdTN3RBMnJz?= =?utf-8?B?dGQyUTV3L3g5cHJxdXp0aGFteTdUTDVDOUUrS3VJZXN4WXlyRjB0OFJqLytx?= =?utf-8?B?MUZDOGVOOGI4ZzRmR3R1djU2anp0ZG9DQ2oyMmw0WUtsNXRONVUyck9wWUpS?= =?utf-8?B?azErME9qL2xBU09PTnpTZEtQa214bHArYXVOSWlUOVhSK01BcjN1RjJBeXF0?= =?utf-8?B?Y1lCSVVhTVJzeXVUTkhXNDdFN1lKTm5FN2orM1NqbkhVOW1QZUJSZUJtd2RT?= =?utf-8?B?NVlLQTJsSVdZOTFWYUFnWlJGZFRNTTVTQUxpWm5jOGQ2Z3c2by8zVlJySGxM?= =?utf-8?B?UzBTemFJVzhNOTlJYmNCNHRLaFNQaTVIZUpKRFR3U3pHN1FPOGQ1T3VWZVF2?= =?utf-8?B?U2NRTmwvZTQ4aGFmd1pPNkJlalEzRWV1dERhNENwWnFHbDVVNkVzeWxrM0p6?= =?utf-8?B?OFdTVjdEc3czSXYweFA5MTNtNHB1ajJoWEpBc2tiRHlhSHBlVWdnYU5obE5o?= =?utf-8?B?Ymh3OUNNZXZ6UHk1eTFMMlRVd25sNVRwdWFEZjBJTjlhWEpBOVZycFVNNHNE?= =?utf-8?B?S2RMRTIzYVBHcTlsbksrL1NaWlQ1bloxTkt5UDdpNzcwVzNDMDdRRGdoWitD?= =?utf-8?B?QitrZ2RVRGFQeWEvSDNlQnlXTFJKT3FodFpDTFRqSGVzc01nWkdCR2k0TkF4?= =?utf-8?B?K0Ftc2lCcWVzYnhvNXYzZXlyaDBWYkpJOWp3QTZXNUwrT2s4WHdSTXhxSUY3?= =?utf-8?B?d0QzZE1DcDFtMTZKa1U5V3N1RElNakE0bmxYQ1ZXbncwZXJ6QnlBTjV3MmQy?= =?utf-8?B?S0VvRzhPeTF3RFNHTTQweS9XdWdZcXpXcEZLNmZwN1huU09QWVR0a1g4N1FM?= =?utf-8?B?N1FaU2RoSzFITXZBL0huYWIvenoxSGVMSW0xbXpEcnRDa2VSQ1IvNkxlWHJx?= =?utf-8?B?eTNQVXR1ZDRZeUdRQTRwK1UxQkVJaXFsS1JVYnZ2azk1QS9KSlVHV2gralU1?= =?utf-8?B?cGtzeTlZM2puNjMzbFBEcEVLdnM0RVBScFpaUU1KYmVjY2VFZk0vcThLVEw3?= =?utf-8?B?VXJ4c2dLZzZTalNTK3FPalVPclFHdjZVUG5pUDZ6SnJsMytoRXo0dU9VN0xl?= =?utf-8?B?aWxYNWJJb29GVVdqZnVtZ2x6a1hPSGszT3VpcVZNWnhRbk9YYVJURHFVcFFl?= =?utf-8?B?RnpEVlFqUEZsVXFyTDFMaG5wa1prd0pYMklSTUxwZThkQ1RpN0hDd1ZTUldy?= =?utf-8?B?MmdCbDg2T1hHUW95V2xSZGM3M09FdTF4RjNrREhsRUl5VEVNNnNSTWptMU1S?= =?utf-8?B?NzJqNi9HUU85c1B3UjdTanhxZjlqb1NrRHVvSlZnSEFQSzlIRVQycXVnd0ht?= =?utf-8?B?VDBzMGtMQ1lJQ1RTZGl2WTlqY3dYWFptcUducDBnZG9CdVcvbkUrZ0xzSWlS?= =?utf-8?B?RkpROWpCU1hxaGJKcnF3dUoyYi8zUjRxZnQybFVYUGlPY1BDaW1SSkRhY2JB?= =?utf-8?B?Z2ZqWER5VlFUUmZCZFhHcno0TFdFOS9vWS8zek5RM2plTXBZaVpqRjVpVTRQ?= =?utf-8?B?L3dRYWUwK21kaEdHRHBkdmU2dGJlK1BmV1V5dGQxNjZqTkk3RjNWVTVvM2hV?= =?utf-8?B?bFVBR29uNHdyZDZPcGF3REU1L09OT0VpU0ZvbVluYlplQkxXUFV6bFFxMmE3?= =?utf-8?B?ejJCbHRjUnZVMWNORUNhUitPcW45alI3a05TU2lKZFZNa2h5aDI1YjNGSjZO?= =?utf-8?Q?MmRHKfbKDjuDkI1TNX3cU3SQX?= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3ef6b043-0c3a-4b3f-2ee5-08dad376912c X-MS-Exchange-CrossTenant-AuthSource: VI1PR08MB3919.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2022 08:32:22.6070 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: H3dyoQ694H1+z4Z4sSXCBzjjtJ+oE6o+tZ6zVs4VtWeZWmgxCLa9VNkQUGhTPQpP5/lof5kvg7EVmRyMuIn1IA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7718 X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,KAM_DMARC_NONE,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 12/1/22 03:16, Thiago Jung Bauermann wrote: > > Simon Marchi writes: > >> On 11/25/22 21:04, Thiago Jung Bauermann via Gdb-patches wrote: >>> If the remote target provides an expedited VG register, use it to update >>> the thread's gdbarch. This allows debugging programs that change their SVE >>> vector length during runtime. >>> >>> This is accomplished by implementing the thread_architecture method in >>> remote_target, which returns the gdbarch corresponding to the expedited >>> registers provided by the last stop reply. >>> >>> To allow changing the architecture based on the expedited registers, add a >>> new gdbarch method to allow arch-specific code to make the adjustment. >> >> I get this when applying, can you address that? >> >> Applying: gdb/aarch64: Detect vector length changes when debugging remotely >> .git/rebase-apply/patch:164: indent with spaces. >> "gdbarch_dump: update_architecture = <%s>\n", >> .git/rebase-apply/patch:165: indent with spaces. >> host_address_to_string (gdbarch->update_architecture)); >> .git/rebase-apply/patch:186: indent with spaces. >> gdbarch_update_architecture_ftype update_architecture) >> warning: 3 lines add whitespace errors. > > This is because gdbarch.py generates these lines in gdbarch.c with > spaces-only indentation. I will send a separate patch to fix it. > >> I think the idea makes sense. Short of adding a packet for "get thread >> architecture" or extending the stop reply format to add a note about a >> thread having a special tdesc, I don't see another way to do this. We > > I guess we could define such a packet, but this approach is indeed > simpler. > Just a FYI, we now have a feature hash for determining the target features for aarch64. It is a 64-bit number and doesn't rely on positioning of registers. This situation with vg/SVE will also apply to svg/SME in the future. >> can't read the vq register using 'g', because to interpret the 'g' >> result, we need to know the full architecture. We wouldn't know for >> sure the offset of vq in the reply. By using expedited registers, we >> just need to make sure vq's register number is stable. I guess that is >> the case? > > The register number is determined by the function > aarch64_create_target_description. If SVE is supported, VG will always > have the register number 85. If not, then AFAIU the register number will > be unused (since the PAuth, MTE and TLS features only have a few > registers). But it could potentially be used by another feature in the > future... > > Do we have to reserve the number 85 for the VG pseudo-register? > >>> @@ -8068,6 +8078,21 @@ remote_target::process_stop_reply (struct stop_reply *stop_reply, >>> /* Expedited registers. */ >>> if (!stop_reply->regcache.empty ()) >>> { >>> + /* If GDB already knows about this thread, we can give the >>> + architecture-specific code a chance to update the gdbarch based on >>> + the expedited registers. */ >>> + if (find_thread_ptid (this, ptid) != nullptr) >>> + { >>> + stop_reply->arch = gdbarch_update_architecture (stop_reply->arch, >>> + stop_reply->regcache); >>> + >>> + /* Save stop_reply->arch so that it can be returned by the >>> + thread_architecture method. */ >>> + remote_thread_info *remote_thr = get_remote_thread_info (this, >>> + ptid); >>> + remote_thr->expedited_arch = stop_reply->arch; >>> + } >>> + >>> struct regcache *regcache >>> = get_thread_arch_regcache (this, ptid, stop_reply->arch); >> >> >> What happens with threads that are not yet known? Imagine the process >> starts with SVE == X, the main threads spawns a worker thread, the >> worker thread updates its SVE to Y, and the worker thread hits a >> breakpoint. This is the first time we hear about that worker thread. > > I tested this scenario and... it sort of works, but not quite. When the > unknown thread hits the breakpoint, gdbserver sends a T stop reply > packet with the new VG value in the expedited registers. It will be the > first time we hear about that worker thread, but at the same time we > will also learn about the value of its VG pseudo-register. So GDB > reports the breakpoint hit event and gets to the prompt as expected. You > can even print the new value of the VG pseudo-register, or any other > expedited register such as PC or SP. > > It's only when you try to print the value of a non-expedited register > that you get an error indicating that GDB and gdbserver don't agree on > the size of the SVE registers (“Truncated register 51 in remote 'g' > packet”). > >> If we don't do a "gdbarch_update_architecture" for it and save it >> somewhere, we'll never set the gdbarch with SVE == Y, will we? > > We do that in remote_target::process_stop_reply, and I was under the > impression that it happened early enough for GDB to have the correct > gdbarch available when it needs it, but unfortunately that's not the > case. > > I will add a testcase exercising this issue and see if I can find a > solution. Thank you for spotting it. >