From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80070.outbound.protection.outlook.com [40.107.8.70]) by sourceware.org (Postfix) with ESMTPS id 30FF93858D38 for ; Tue, 20 Sep 2022 08:07:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 30FF93858D38 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=K+eudYsi125cnCS1W29uzoRwNelOehYPrewWn2th6xBIm0ZJhdD6yv8Y1+atB53qa77w9xkTo6z7iW71UaSoURwEM0+flqBCsv5gk0ClgbgGUhsp2l6sqBqQURjmDXtekFK88U/X5y7bwNQrTFgKwOdhr0HpM6AvYbDniIWc7KQZ06pNAcaRgkGSTNuHe4cJqUngLvKUgfYdVzBTNp7eAatOF0zILJooIR56uSKUKfrHR73r9gJNe8mtr+QvIWDyiYi2V49VNI8yizBNXi7gL5sO6dO1ha7XLRd7T2UUgaAFviVSl/+wZBrAtV/MYgKk6stJUDzIPXBEtPvggHtcrg== ARC-Message-Signature: i=2; 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=ubekKyXENr9OM+5VJo8/rbkN4s5OAgWFENmmloeTiqY=; b=LLt7lm4chd46fDxzlLE8zDnWuWvtapWf6sFfq16HmLvOk3PQ0zG6ublyDOGknYdFgRG2Soa/3GB1vBsj1DuqbqmGIs/2CfkHQLhz8+TaLC2Nv7OGzwWhGqWmozGVWAIxuUU4obpgam6Xtgj79elmIVkGmdXf5juRKaiteDB8GxR9e4lNdiB0tDy89QJxbqNTZAOfDdwP9tc5ik1vZXbxfKNSGRHN39U7dDO0JHXhCG4V9F9IDcWGSPzEpKcZlXFzMIM5Z0W2NoE5bB01JNARPdMp/VOaNMFtHBT5DsnxBwnBPj8WVA5/2RQUq2wp7Jff4nTjF7ueir06XExir6KkOw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) Received: from AS9PR04CA0154.eurprd04.prod.outlook.com (2603:10a6:20b:48a::17) by AS4PR08MB7783.eurprd08.prod.outlook.com (2603:10a6:20b:517::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5632.21; Tue, 20 Sep 2022 08:07:32 +0000 Received: from VE1EUR03FT058.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:48a:cafe::99) by AS9PR04CA0154.outlook.office365.com (2603:10a6:20b:48a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5632.21 via Frontend Transport; Tue, 20 Sep 2022 08:07:32 +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 VE1EUR03FT058.mail.protection.outlook.com (10.152.19.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5632.12 via Frontend Transport; Tue, 20 Sep 2022 08:07:32 +0000 Received: ("Tessian outbound fc2405f9ecaf:v124"); Tue, 20 Sep 2022 08:07:31 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: b313420497a45f24 X-CR-MTA-TID: 64aa7808 Received: from 618afab0da88.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 53F5BD53-5632-4559-857B-6B34836E4B0C.1; Tue, 20 Sep 2022 08:07:24 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 618afab0da88.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 20 Sep 2022 08:07:24 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c38S69B8oGdvMuPbOv54/ckAWIPfHHKu3zJo7fOondJ/x5mKBbWmsD3laCDAzIJm/nsWpoI7KI2/GhOtw8zGuGsbbcowAzJ05dAKpFE3xKBarjHUnQQWG1RzNrsQHWE0mo533tFC2mLvSSDRijvOFvVOrVDm3FOUNF1GwtDKZ34skIsYFKb7Y9WR1PpEm2id1jqWlOXPFgB4jI6QieOyEwQGyFPXz1FstPZwOTXk2L4SvEu9596pIIhxu732Q+KE/jmtAPGnBrOSesm/2qM9vreJ6Tnt9lrjAAaKj5oWnzEZhq2pT/2++hTql2jF6rSY3fqEK0UZ9t+S3BM99r5Gcw== 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=ubekKyXENr9OM+5VJo8/rbkN4s5OAgWFENmmloeTiqY=; b=C22KW2AiWV5ofWalIPM0Gc0nQfGPK8wHPsLcy6VhSNeZ3zv6hzoBBlX8joj1ufJfXnfs2OLhCkv1MGwQgdguigBdedxcdEOhbwE0J8nr2vYPVetjtJWpOXdkheYC0wq3ig5D0BRzFTeIA8ZZ6NCcyeWYtWPd+sqgXqJSZJqtXDrMSfUqkzwejrYHo0x3G2pqAIpi3vwZzDZQsaQariNQSKof0oyyxQyQffc56OHpqa7Cix3wMerfEg3VpnL3WBV7rNbFW/6hR7DCvUfNqMSYGbwtFghyqUSmi+JBN/dyWg5On0mQUAC6AE6EChkyg8BGGYsvYEFTnnZlArVAOdCLyw== 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 GV1PR08MB8282.eurprd08.prod.outlook.com (2603:10a6:150:a3::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5632.16; Tue, 20 Sep 2022 08:07:22 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::c5f9:a25b:a5f2:6094]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::c5f9:a25b:a5f2:6094%5]) with mapi id 15.20.5632.021; Tue, 20 Sep 2022 08:07:22 +0000 Message-ID: <6b12308f-d54a-129c-b8d9-5d34d09bb5bb@arm.com> Date: Tue, 20 Sep 2022 09:07:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH 3/8] gdb, gdbserver/aarch64-linux: Allow aarch64_sve_get_vq to return error Content-Language: en-US To: Thiago Jung Bauermann , gdb-patches@sourceware.org References: <20220908064151.3959930-1-thiago.bauermann@linaro.org> <20220908064151.3959930-4-thiago.bauermann@linaro.org> From: Luis Machado In-Reply-To: <20220908064151.3959930-4-thiago.bauermann@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0124.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::16) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|GV1PR08MB8282:EE_|VE1EUR03FT058:EE_|AS4PR08MB7783:EE_ X-MS-Office365-Filtering-Correlation-Id: 1f96c305-183d-432e-e6ef-08da9adf2b6f 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: 16XxX6Z4UhFSWz7dc6mDu78mhdL/74jeB5ZPM6MenGjl/ex/dac5qdGrWzLXDnbbch+ZRODB6LKz89zoup8iT12oUnbs7zFlJdn8jcuiNAMg7EEXtSqB1JSAFB8oBWgbydpKqhpFkQtQr152SAPdUiRnLmzJ4cP++gFQwJ8qWgjrbQaaNS6Re4it+6Me/6ncXHwgpxiBRcHKmhY9UL1785mScrik4dJzRU3262y1T6h6+25n+3AJzVGFpA3v1VXkPlW47zBQlU6TwHZtczzwQukXwffSD0aVdJaqohJwn6OcdoGVzV2FHOQPXJm9JoO4G1E7KtUCDYnn4FC8jAD9x4kZm5GEnFLV7t433pO/uf2IDhi0kXSIWuK11JV6Y2YjoDN9wjZ9uQC+39CBL/USJv2y1aw+NHlO2v/5aXiQQd4xJFvP4N+P53jVyBMiX+oKPbcE5xk1jTVzDAXl6vxpiSCD1SbWnuBRTh3/rssl42HMwAhoIb/3155YqZQeU3BNPmoBfejwyOoXhC2A99oHqYWEz3/Vztu9ais95yZvk92c+0QAz9IrnbmkQAcvfnxjUexjzsgBSognNo/y3KcdAQ4WPDpFYVYVYgloLouyc7Y9/3F1A9/SRUSFauCOy841xGuUEy/TJI4p8S/O/VoqES2a9lh9DnX8klsZpIyU5sWb/i8FF2M2eEFi4Pkl5DaWrcPy0LhSQ33J/iOdmH9+7h5sXXBTdUElyAh+cDwSNLUNXURkPcpzDHSW1jYl8tsocklweXp3uNCyr1Ao0LogjAY6Fp+h1L1nSZ1fSh/pvew= 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)(136003)(366004)(39860400002)(396003)(346002)(451199015)(2906002)(31686004)(44832011)(5660300002)(2616005)(6512007)(6486002)(53546011)(31696002)(478600001)(38100700002)(8936002)(86362001)(83380400001)(41300700001)(186003)(316002)(66946007)(26005)(8676002)(6506007)(66556008)(36756003)(66476007)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB8282 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: VE1EUR03FT058.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 08e8d4d9-2e12-49f1-8dfb-08da9adf2572 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: S3ca+dlg213HUZj4LF7VZ2f9wVxnFfaMuJ+wDOazJppx3h1xyZ4TjKMrLFYCI8OGlR3hPoCDQ8rZuhxGSadcs2wszf62Yr4bTV3rxtRvFGCTls2KR0grlIJok33XBILCU86H7OdINd8h8AcVN6os2GLOkOVVKrf7c2as+m839hotp5i+XNGu1LQ+mfnOhuprkklgk+3aJq35b+wjEYf/qlM21FWI4k8OS5SkhvoR/0g7KqxHhwnvwshvIchxE9KiGUWV2Spz04EvdvRq/LpgF6dVwsYLc00pbZjKA6Z4c6rWRY+t++cErfMNTbF0Tce46hy4tx0dprrnyz73vc7FWpPsO0zdhpqWHVp27Y24wBuNwS5j1cUFHdb3Kp5woJVC7PjYoJBmWuYq4usKPv1/0LMJL9S784/ErqRrqboJGmhF4LI0/Lz4H8ZVOJMgWajqjC0v2duIWqL6ZEYThT4dCAG2YFbDmFczJ/eVFliBpgB7HCfmBrYBmhQ7p0OBimry44mUkp+6bu7iznscf054V2rjweLsynWwCW5NHxlQA5h4D/pHb2OUzAkFgd/B/KPacGCtSbt6fnc8ovMTSAgQImL3zW/86RvKZdWRT9JNxWWB9aIzxV6mD51FnjrGckyWE/hFrNyeQ7t4PKGn9B1U44Ex2eCkuMAXNaoJNLjRlD2yf4TcJpGzc5rMQ0LvRpCoXHxk9O2xdNFa1J8kuOee1nCdN71PRBlXNdhge9fkUokVoGi5PZveY+u1LigvjpaZ1Cx1/WXbG+h2lniBGYrSvy1WUQHFMNd2GsDqynR3IUfAO1oY98q8Lhf6wd+JZKbM 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)(346002)(39860400002)(136003)(396003)(451199015)(40470700004)(46966006)(36840700001)(53546011)(26005)(6512007)(2616005)(6506007)(31686004)(81166007)(44832011)(2906002)(478600001)(6486002)(356005)(5660300002)(36860700001)(82310400005)(31696002)(82740400003)(36756003)(40460700003)(47076005)(336012)(186003)(40480700001)(41300700001)(83380400001)(8676002)(86362001)(316002)(8936002)(70586007)(70206006)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2022 08:07:32.1141 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1f96c305-183d-432e-e6ef-08da9adf2b6f 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: VE1EUR03FT058.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7783 X-Spam-Status: No, score=-13.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Tue, 20 Sep 2022 08:07:52 -0000 On 9/8/22 07:41, Thiago Jung Bauermann via Gdb-patches wrote: > If ptrace fails, aarch64_sve_get_vq assumes that SVE isn't supported. > Because in a subsequent change this function will need to be called from > low_new_thread (which can be called whe the inferior thread isn't stopped), > it will need to distinguish between ptrace errors due to SVE not being > supported from ptrace errors due to the inferior thread not being stopped. My understanding is that we will always be able to validate supported features when we start/attach to a process. So if, say, we detect SVE support through HWCAP's in the beginning of the debugging session, that will still hold for any thread that is spawned. What may change later on is the VL (still, very unlikely). When a thread is spawned, it will inherit SVE settings from its parent. From the Linux Kernel SVE documentation: In particular, on return from a fork() or clone(), the parent and new child process or thread share identical SVE configuration, matching that of the parent before the call. Is that something we can use here? I suppose there may be corner cases where the parent spawned a thread and changed its VL size etc. If we can't and a thread is running, we won't be able to tell the VL, but we have a state that is meant to indicate "unknown VL", don't we? Maybe I'm misremembering, but -1 used to indicate that. > > This patch changes the function to return -1 in the latter case and adjusts > callers. When a caller is allowed to propagate the error, it does so. When > that isn't possible an assertion is added to ensure the error isn't missed. > --- > gdb/aarch64-linux-nat.c | 14 ++++++++++++-- > gdb/nat/aarch64-sve-linux-ptrace.c | 18 ++++++++++++------ > gdb/nat/aarch64-sve-linux-ptrace.h | 2 +- > gdbserver/linux-aarch64-low.cc | 6 +++++- > 4 files changed, 30 insertions(+), 10 deletions(-) > > diff --git a/gdb/aarch64-linux-nat.c b/gdb/aarch64-linux-nat.c > index eda79ec6d35c..633cbc08796c 100644 > --- a/gdb/aarch64-linux-nat.c > +++ b/gdb/aarch64-linux-nat.c > @@ -784,8 +784,14 @@ aarch64_linux_nat_target::read_description () > CORE_ADDR hwcap = linux_get_hwcap (this); > CORE_ADDR hwcap2 = linux_get_hwcap2 (this); > > + int vq = aarch64_sve_get_vq (tid); > + if (vq < 0) > + /* A ptrace error happened so we can't determine the vq value. > + Give up trying to read a target description. */ > + return nullptr; > + > aarch64_features features; > - features.vq = aarch64_sve_get_vq (tid); > + features.vq = vq; > features.pauth = hwcap & AARCH64_HWCAP_PACA; > features.mte = hwcap2 & HWCAP2_MTE; > features.tls = true; > @@ -894,7 +900,11 @@ aarch64_linux_nat_target::thread_architecture (ptid_t ptid) > /* Only return it if the current vector length matches the one in the tdep. */ > aarch64_gdbarch_tdep *tdep > = gdbarch_tdep (inf->gdbarch); > - uint64_t vq = aarch64_sve_get_vq (ptid.lwp ()); > + int vq = aarch64_sve_get_vq (ptid.lwp ()); > + > + /* If ptrace fails we can't determine vq, but the thread_architecture method > + always succeeds so all we can do here is assert that vq is valid. */ > + gdb_assert (vq >= 0); > if (vq == tdep->vq) > return inf->gdbarch; > > diff --git a/gdb/nat/aarch64-sve-linux-ptrace.c b/gdb/nat/aarch64-sve-linux-ptrace.c > index 019d2d65d89a..62f7fc5f56e1 100644 > --- a/gdb/nat/aarch64-sve-linux-ptrace.c > +++ b/gdb/nat/aarch64-sve-linux-ptrace.c > @@ -30,7 +30,7 @@ > > /* See nat/aarch64-sve-linux-ptrace.h. */ > > -uint64_t > +int > aarch64_sve_get_vq (int tid) > { > struct iovec iovec; > @@ -43,13 +43,19 @@ aarch64_sve_get_vq (int tid) > 128bit chunks in a Z register. We use VQ because 128bits is the minimum > a Z register can increase in size. */ > > + errno = 0; > if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_SVE, &iovec) < 0) > { > + if (errno == ESRCH) > + /* The process isn't stopped. We can't determine SVE support or the > + value of vq. */ > + return -1; > + > /* SVE is not supported. */ > return 0; > } > > - uint64_t vq = sve_vq_from_vl (header.vl); > + int vq = sve_vq_from_vl (header.vl); > > if (!sve_vl_valid (header.vl)) > { > @@ -103,10 +109,10 @@ aarch64_sve_set_vq (int tid, struct reg_buffer_common *reg_buf) > { > /* If vg is not available yet, fetch it from ptrace. The VG value from > ptrace is likely the correct one. */ > - uint64_t vq = aarch64_sve_get_vq (tid); > + int vq = aarch64_sve_get_vq (tid); > > /* If something went wrong, just bail out. */ > - if (vq == 0) > + if (vq <= 0) > return false; > > reg_vg = sve_vg_from_vq (vq); > @@ -123,9 +129,9 @@ std::unique_ptr > aarch64_sve_get_sveregs (int tid) > { > struct iovec iovec; > - uint64_t vq = aarch64_sve_get_vq (tid); > + int vq = aarch64_sve_get_vq (tid); > > - if (vq == 0) > + if (vq <= 0) > perror_with_name (_("Unable to fetch SVE register header")); > > /* A ptrace call with NT_ARM_SVE will return a header followed by either a > diff --git a/gdb/nat/aarch64-sve-linux-ptrace.h b/gdb/nat/aarch64-sve-linux-ptrace.h > index 5c264b395313..90920bc48ef3 100644 > --- a/gdb/nat/aarch64-sve-linux-ptrace.h > +++ b/gdb/nat/aarch64-sve-linux-ptrace.h > @@ -43,7 +43,7 @@ > /* Read VQ for the given tid using ptrace. If SVE is not supported then zero > is returned (on a system that supports SVE, then VQ cannot be zero). */ > > -uint64_t aarch64_sve_get_vq (int tid); > +int aarch64_sve_get_vq (int tid); > > /* Set VQ in the kernel for the given tid, using either the value VQ or > reading from the register VG in the register buffer. */ > diff --git a/gdbserver/linux-aarch64-low.cc b/gdbserver/linux-aarch64-low.cc > index 5d4d667dfa42..576925838f49 100644 > --- a/gdbserver/linux-aarch64-low.cc > +++ b/gdbserver/linux-aarch64-low.cc > @@ -823,8 +823,12 @@ aarch64_target::low_arch_setup () > if (is_elf64) > { > struct aarch64_features features; > + int vq = aarch64_sve_get_vq (tid); > > - features.vq = aarch64_sve_get_vq (tid); > + /* If ptrace fails we can't determine vq, but the low_arch_setup method > + always succeeds so all we can do here is assert that vq is valid. */ > + gdb_assert (vq >= 0); > + features.vq = vq; > /* A-profile PAC is 64-bit only. */ > features.pauth = linux_get_hwcap (current_thread, 8) & AARCH64_HWCAP_PACA; > /* A-profile MTE is 64-bit only. */