From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2068.outbound.protection.outlook.com [40.107.20.68]) by sourceware.org (Postfix) with ESMTPS id 007463833A03 for ; Wed, 7 Dec 2022 17:06:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 007463833A03 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com 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=LcoIty3Cn2xMvRG8/HJckPPE3Z8KvmJaoBAGFb0Z21s=; b=AwE1/P6XucnGCY7/fpxE7U5AMVJwc6UP7uZo45fMzspDG0tGbwgWZPcGWJfoSg63ME1Dui2riv0vPapNyClw6RejlB+Tdx2CvdK0lX6PlAUYgTx7pjmF9iBoqZEeieHTT8ZVRTrGCM3MXSNnyCfO4CTAu1qrGEii/A8BXxs9irI= Received: from DB8PR04CA0019.eurprd04.prod.outlook.com (2603:10a6:10:110::29) by AS2PR08MB8454.eurprd08.prod.outlook.com (2603:10a6:20b:55a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.14; Wed, 7 Dec 2022 17:06:04 +0000 Received: from DBAEUR03FT035.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:110:cafe::58) by DB8PR04CA0019.outlook.office365.com (2603:10a6:10:110::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.10 via Frontend Transport; Wed, 7 Dec 2022 17:06:04 +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; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DBAEUR03FT035.mail.protection.outlook.com (100.127.142.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5901.14 via Frontend Transport; Wed, 7 Dec 2022 17:06:04 +0000 Received: ("Tessian outbound 2ff13c8f2c05:v130"); Wed, 07 Dec 2022 17:06:04 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: ac710c3a3c32b3c3 X-CR-MTA-TID: 64aa7808 Received: from e1b184ffb651.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F3A85DDE-1545-4FD0-B56D-FE59DFA2E431.1; Wed, 07 Dec 2022 17:05:55 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e1b184ffb651.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 07 Dec 2022 17:05:55 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VKYTYvIsxqDw9vhw14DTUF0GuSHUm1vfzXjZwQI0J1/4R4G4YvFMzVrTMjafLbN0wx6+iJ8ZPf87lPVJUEryBZHdOm9qDum6TA87+AV3/85U8tN+kWsjXvIpScTZseeGSBsp1uoivOkCUeBcREF9tCMnPgowiN7+rUVJBgnU6s2RjrShMCMuZRUjKxPfD5y1xbEVQQ8xaVttOqxzShASORGIqdn+h9Oz3kTzYr5uyMb6k6BTmKSPQ6w5q6wuNOV/AjT7YYZ+dGI3St6OsTn936JU9BtYnx/0Ou8kDglPVreK/FZtUOyX8i9pKU47E/ByALmxMLWrIuK12XSZ2fP8bQ== 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=LcoIty3Cn2xMvRG8/HJckPPE3Z8KvmJaoBAGFb0Z21s=; b=fYD6hed4RiJSJ8nD/lOCOmDAa9doguRAMH3Aa6c78+qgDfUeBzHRyeI4cvQggcJnPRuWw4BAkIJaS9W5uIxXeC1ZvwK+/OnugbGD//s52DNWj/Q1n7+rFt9S/gcv6kM5lFzgR5JAztrEJb9dbCuN6CGBVCHDygrtfLR33NUBFYrKnb9bmwLMGUOzN3usPerNvsUKed8f86TrN/AAQalt3IWbvuZp+Z18lS+kZe3l9gL5vZhKDcuqURhZwUQx7s+eDKu8XZJieEKei3qGFdvA6f79tjkSPpcKxrHbBo2lG+xg4MOqvaCla4xhn1SFtlkxugctVRZtTCj+RFszJkk3iw== 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=LcoIty3Cn2xMvRG8/HJckPPE3Z8KvmJaoBAGFb0Z21s=; b=AwE1/P6XucnGCY7/fpxE7U5AMVJwc6UP7uZo45fMzspDG0tGbwgWZPcGWJfoSg63ME1Dui2riv0vPapNyClw6RejlB+Tdx2CvdK0lX6PlAUYgTx7pjmF9iBoqZEeieHTT8ZVRTrGCM3MXSNnyCfO4CTAu1qrGEii/A8BXxs9irI= 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 VE1PR08MB5869.eurprd08.prod.outlook.com (2603:10a6:800:1b2::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.14; Wed, 7 Dec 2022 17:05:44 +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.014; Wed, 7 Dec 2022 17:05:43 +0000 Message-ID: <0605407e-a9bf-06c1-c513-e6202181a51f@arm.com> Date: Wed, 7 Dec 2022 17:05:39 +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 Cc: gdb-patches@sourceware.org References: <20221126020452.1686509-1-thiago.bauermann@linaro.org> <20221126020452.1686509-7-thiago.bauermann@linaro.org> <87edtdiijv.fsf@linaro.org> From: Luis Machado In-Reply-To: <87edtdiijv.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SN6PR05CA0033.namprd05.prod.outlook.com (2603:10b6:805:de::46) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|VE1PR08MB5869:EE_|DBAEUR03FT035:EE_|AS2PR08MB8454:EE_ X-MS-Office365-Filtering-Correlation-Id: 3abd1ad7-7a81-4c96-f629-08dad875531f 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: DMxKm/r5ndqDZNBT2NyP79tFYA9CZMCSskc4lvrMay6PGjMbMIZM1rv9BMkV9TcPQIRZnMFofa9lJhFkZJKmNhPwcrDXcDE2XmqfU/7g1XRDbr8Eezzyb4i/mRWWNNRz8ZtyRJ1XWz/lJNdgZ/1ICz99THAtmJbB2XV2c5N+tP/Q21OthSPtWE8bhEUm7R1dfyQBc8ENS1CtA8z4R4XdX99n2pUMFZS4LULQsEc9gGeUNaH8qUPC+qTsdNlVoahFuWzQApBLaN8h0eOTILDcmedx2inse6ayZmxH+x41gbBXTMEMG/R4z8h0PsrLfPMFmD9RB8keGQau2bEDuIwuUIuehsu79IoZTaYHHSuAz8x55ZJrnNDTA7mODJn8cwbitEEU20L3XAe/4WxjwygxSbtBKx6R1nuP2KWEhlj54UdAgmqcF5WUJjk0QchLduTY2PMtUFhLnAiZKW9KmBd1BLX6QRGDxOzAqaSjNnx6d7dUsg+ElVDqaGVDte2b+L1P3P/ZmG8XLE9AMuu1UJibc7p0PuATIPrXJgsIJ31SEkfm1oJCmkLKd4G6zMp5CfJXg9Jfj7g6mktL6m1rwUja+lEmMl+xj8Bogvg1p4UtPWhZQQwFgcN0kUAMr+2Wpde1NbDHwU47FWedwCf62+mVrDp3QafI21SbQdKuMFXPa9IXzAtM2x56QwnpN+dx0SRmXAttU23HJs9vlWF3t4s0g6nbmq3F+nq6y/ICqhws5M0= 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:(13230022)(4636009)(376002)(366004)(346002)(136003)(39860400002)(396003)(451199015)(36756003)(66556008)(66946007)(41300700001)(5660300002)(66476007)(8676002)(4326008)(31686004)(6916009)(316002)(8936002)(44832011)(478600001)(53546011)(38100700002)(26005)(6506007)(186003)(2906002)(2616005)(6512007)(6486002)(6666004)(86362001)(31696002)(83380400001)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5869 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: DBAEUR03FT035.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 87b9b0b2-af80-4d49-2b8a-08dad87546ac X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: PBvDCYddTTICPMhsnN7zCiPxzFgmwxeBLHaa1B5BpUnQPxIzb/Xnxqrb106SoiZlJUmnOKtaR6tnl1T55rj8O3I42QHvDiKHBVDT/HAUcXwvm/PmGCetKDWp7v84SUWvVU59ISmPmcS/ITrNXg8djEblDvSyALUzLMDqw14pHTaNs0Qp8LChGlr7CowtokQi8wLQ5FO69gX04uMeROnuQmS4dtbUyWuO4MONRmyMrz07bVyNxbsCFobjTfgKXNcoZTvtY4Do7LhccWVPVMSftRW6LSGdhbUqZx2OpruJ/jrW3w2Lsg95Lw5ic4GYPV8Kjf4t55ElHR6jn3xoR/ngKQrYhgGXhJd+OV+FR3iZ3Vtv+/xp9rBSXZj3GXtmWZZP1MgRLVOvDG9il6f3gI8Mwa5nNnBhC5rCvfWznJukgsyGn28nPDdM6nAMa/VSXL4O87W3NEJkVmFI5kePOBB9pKIl4GSrfF5Cm31zBh3vco2W78g/OsHDPneVrR5dBWOv3o+t+6ZGYOZh7zR8GqeGqqBfVfZCsHOQAEIKw13Vh+i2pS67e+/SvUyf0Nt1ksUMOyjqeDDs7zTCEJ7W42NughyxnCO1IpynpA9rifwQ1BPw1MPTHZIZ9fE9LSwGwp3lQn73TgwBwGxbJaBcZnohUUNiUuxCxpegNED7QpfKg1H/AG6uKyZIKMo4dOIu/SflnvcdNlINXAdEarJZfObnPiNYi92cWL62qdva9yMXEck= 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:(13230022)(4636009)(376002)(39860400002)(346002)(396003)(136003)(451199015)(40470700004)(36840700001)(46966006)(36756003)(81166007)(2906002)(82740400003)(36860700001)(5660300002)(44832011)(6862004)(8936002)(356005)(47076005)(186003)(336012)(2616005)(31696002)(86362001)(83380400001)(316002)(31686004)(40480700001)(6486002)(40460700003)(478600001)(82310400005)(70586007)(41300700001)(4326008)(70206006)(53546011)(8676002)(26005)(6506007)(6666004)(6512007)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2022 17:06:04.3723 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3abd1ad7-7a81-4c96-f629-08dad875531f 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: DBAEUR03FT035.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB8454 X-Spam-Status: No, score=-6.4 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,UNPARSEABLE_RELAY 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/5/22 22:37, Thiago Jung Bauermann wrote: > > Luis Machado writes: > >> On 11/26/22 02:04, Thiago Jung Bauermann wrote: >>> @@ -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); >>> @@ -14382,6 +14407,23 @@ remote_target::thread_info_to_thread_handle (struct >>> thread_info *tp) >>> return priv->thread_handle; >>> } >>> +struct gdbarch * >>> +remote_target::thread_architecture (ptid_t ptid) >>> +{ >>> + thread_info *thr = find_thread_ptid (this, ptid); >>> + remote_thread_info *remote_thr = nullptr; >>> + >>> + if (thr != nullptr) >>> + remote_thr = get_remote_thread_info (thr); >>> + >>> + if (remote_thr == nullptr || remote_thr->expedited_arch == nullptr) >>> + /* The default thread_architecture implementation is the one from >>> + process_stratum_target. */ >>> + return process_stratum_target::thread_architecture(ptid); >>> + >>> + return remote_thr->expedited_arch; >>> +} >>> + >>> bool >>> remote_target::can_async_p () >>> { >> >> Just recalled this. One deficiency of the current SVE implementation >> is that it doesn't have a proper way to hide the Z register when they >> don't have any meaningful state (SVE not active, so we have fpsimd >> state). > > I see the SVE_HEADER_FLAG_SVE being checked/set in > aarch64_linux_supply_sve_regset and aarch64_linux_collect_sve_regset > (though in the latter it is set unconditionally), and also HAS_SVE_STATE > being used in aarch64_sve_regs_copy_to_reg_buf and > aarch64_sve_regs_copy_from_reg_buf. > > But I wasn't able to find similar logic regarding hiding the Z > registers. Do you have any pointers? > There isn't logic to do that at present. This is something I'm pondering for SME, and would possibly apply to SVE as well. But it may be more complicated than useful. >> Given the VL will always be reported as > 0, even if there is no >> active SVE state, gdb will always attempt to show Z registers. And >> those are quite verbose. > > The VG pseudo-register is defined with an int type, so we could return a > negative value to indicate that the Z registers are unused (and the > module of the value would still be the vector granule). Would that > be ok? I think a value of 0 would be fine for this purpose but... > >> In this sense, the implementations of the the thread_architecture >> methods for both native aarch64 and remote differ. While native >> aarch64's implementation is capable of detecting the lack of active >> SVE state, the remote implementation can't. If gdbserver decided to >> drop the Z registers mid-execution (before the SVE state is not >> active), there wouldn't be vg for gdb to make a decision. > > Looking at aarch64_linux_nat_target::thread_architecture my impression > is that its result depends only on aarch64_sve_get_vq, so I don't see > how it's different from the remote implementation. ... Right, but for native debugging we actually call ptrace to extract the vector length. That is completely independent from the XML target description or the available register sets. In the case of remote debugging, the expedited registers are returned based on an existing register description. Take, for example, the following: - SVE state is enabled and we have the vg register. - Program updates the SVE vector length and, as a result, we no longer have an active SVE state (reverted to FPSIMD state) - GDB drops the sve feature from its target description. - Program executes a sve instruction and SVE state is made active. - gdbserver tries to tell gdb what the value of vg is, but gdb doesn't know anything about vg at this point, because it has dropped the sve feature previously. I think this is the downside of using expedited registers to communicate the architecture changes. For this case, returning a full XML would make it easy for gdb to figure things out. But, going back to hiding sve/sme registers when they're not in use, I'm not yet sure that is something we should pursue. I'd say if you manage to get things working with the expedited registers (for the problematic cases Simon and I pointed out), that's fine. > >> I wonder if there is a better way to handle this that would still >> allow us to hide these scalable registers when there is no active >> state. > > I guess it depends on whether you would consider using negative VG > values as better. :-) >