Message ID | 20230418135313.36300-1-luis.machado@arm.com |
---|---|
State | New |
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 308E23881D22 for <patchwork@sourceware.org>; Tue, 18 Apr 2023 13:56:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 308E23881D22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1681826198; bh=dbOk6ir7lmnPvf5bWpf1cr+OHtsJ7Nt9Xbq1zssb/3Q=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=RPac/xMItM9JdsvFKczypM+tR7jeUJzHKNEHGl0DmrB9OHe9Y5VF6I4cNrI9zKVQg VHolPih9aUCA11rt8ykAgocTWI7ZBuph1oaqbIESkFbVn2Zy/MVL9WYtwXFG7sFmrW DSRCs5/XVJhTEtwak2YJuhc5/YQ5CT1QkVUL3gGU= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2052.outbound.protection.outlook.com [40.107.20.52]) by sourceware.org (Postfix) with ESMTPS id 7973C382C14F for <gdb-patches@sourceware.org>; Tue, 18 Apr 2023 13:53:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7973C382C14F Received: from AS9PR05CA0075.eurprd05.prod.outlook.com (2603:10a6:20b:499::35) by PAXPR08MB6445.eurprd08.prod.outlook.com (2603:10a6:102:159::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6319.20; Tue, 18 Apr 2023 13:53:25 +0000 Received: from AM7EUR03FT007.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:499:cafe::1e) by AS9PR05CA0075.outlook.office365.com (2603:10a6:20b:499::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.47 via Frontend Transport; Tue, 18 Apr 2023 13:53:25 +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 AM7EUR03FT007.mail.protection.outlook.com (100.127.140.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6319.20 via Frontend Transport; Tue, 18 Apr 2023 13:53:25 +0000 Received: ("Tessian outbound 5154e9d36775:v136"); Tue, 18 Apr 2023 13:53:25 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 2a4ef9e2661d0a6a X-CR-MTA-TID: 64aa7808 Received: from 11a32988ca38.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 13A5AC31-F922-43E0-AE4B-F7F38F5B8C1D.1; Tue, 18 Apr 2023 13:53:19 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 11a32988ca38.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 18 Apr 2023 13:53:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hUOMWnS/u4Tr2OopqG6p+aJIwgBJaVYZCjTJ2uLIwE2WH3sbcDoeLQea32oMXxvFL5Aw/u4/JL8X3iD2R3qEWTaS6zWy4l4sjMTtIs4JwV188Cou5GdZlNu/B4YU3ML8kPZVS1yt54nYKcs/yy34IloMbTHpX7Tz8ukXofM3bmaRoPOdOnA9ZvNsmPoKtcXfO9R/hMTFJ7tDO/sKBluxsacxFqILwubj01ZXcFEPtbyke8XP6KC8uYEwlg9zOhRIbAqgHbf6a6+Gwz/pQnK3+tHwzNmAiGqkD8uItrLVCI5oGRJp8Fvfty5HqBxf2ug5ASJcDvZXIGuManqc1DZDCA== 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=dbOk6ir7lmnPvf5bWpf1cr+OHtsJ7Nt9Xbq1zssb/3Q=; b=FW8ixxE1qUO1mjKSC9YZwHRFu21BDgmz5N2JH5cQrIQP+UjHWFGZrLFsdNyqza3bj2SRoDk3hQXcLbW5XTn3qv9u2BuCg9larumG0Rs2UrIDmYXIQX5Illt2nyTAq1uJj4VlB97epwBmi/gi8ukozuSDLRIXOY19Ch6oUIET7l0FRO+ATEDT3CiKd2DYY8LjRBxOyXzZA4Ptb64SCYB254BewtoHgX+RANPLa4MbfyVJdXHMUH/Hy0ybFYUczn4WvMqkqF4iZh5oqi3QbE8gIuWQHBXK38wMcozGVcpziVWZHoEgfl7NgQZEnlI06qc6RCYUxQOhTnZIn+n7vTSTsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 40.67.248.234) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=none (message not signed); arc=none Received: from AS9PR06CA0654.eurprd06.prod.outlook.com (2603:10a6:20b:46f::30) by GV2PR08MB9877.eurprd08.prod.outlook.com (2603:10a6:150:dd::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.45; Tue, 18 Apr 2023 13:53:15 +0000 Received: from AM7EUR03FT038.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:46f:cafe::e) by AS9PR06CA0654.outlook.office365.com (2603:10a6:20b:46f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.47 via Frontend Transport; Tue, 18 Apr 2023 13:53:15 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 40.67.248.234) smtp.mailfrom=arm.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 40.67.248.234 as permitted sender) receiver=protection.outlook.com; client-ip=40.67.248.234; helo=nebula.arm.com; pr=C Received: from nebula.arm.com (40.67.248.234) by AM7EUR03FT038.mail.protection.outlook.com (100.127.140.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6319.20 via Frontend Transport; Tue, 18 Apr 2023 13:53:15 +0000 Received: from AZ-NEU-EX04.Arm.com (10.251.24.32) by AZ-NEU-EX03.Arm.com (10.251.24.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Tue, 18 Apr 2023 13:53:14 +0000 Received: from e129171.cambridge.arm.com (10.1.36.32) by mail.arm.com (10.251.24.32) with Microsoft SMTP Server id 15.1.2507.23 via Frontend Transport; Tue, 18 Apr 2023 13:53:14 +0000 To: <gdb-patches@sourceware.org> Subject: [PATCH] [gdb/aarch64] Handle unknown debug architecture versions more gracefully Date: Tue, 18 Apr 2023 14:53:13 +0100 Message-ID: <20230418135313.36300-1-luis.machado@arm.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 1 X-MS-TrafficTypeDiagnostic: AM7EUR03FT038:EE_|GV2PR08MB9877:EE_|AM7EUR03FT007:EE_|PAXPR08MB6445:EE_ X-MS-Office365-Filtering-Correlation-Id: c6d44c99-592f-4815-8a45-08db4014481f 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: Rn8ZcQrwqZUce2gjmST4P9Kwezp/QWbH/+fNNXfDJ2xoMHnL6wXXeXk/zI1V961+s9+mOUTTC6xznu8OZ1AGDoeDINFxtKuiRxQ9FH0WKAIYn+y95Kqj5R+TFb4Yry7xB0MmA0HTDsEZfBAjxnlQ7QHrpufdV1g1nl3YpsHqpeecAGI1e0f5fvKOuovcN4UrZquZuefWqDdGh8Yo8CrqwkmnRK2hWH4vISp7fv/1wfPm+kzStRkS5UagGsPg9CqkRoiqZYpFmyFzcT77mor40BSSrIRhAL3j9/G8hwl4eW91BtVQFufP3g/lnAR6P73tjJghOsAvCPRJup4yyWhD8wV8r8sm+SpGR3tAtorDVR2Enps2NWbcXaDdX4bfrbv9tyMLZwvtkXFTTXW4X+N2Zo2TvMzuNQwhEnRLBfhXioANx45CLj8egK4VNX8aIMViDyszShE0gDRyfXtvu9BVqG00uMocp2tyfepqj+UJkSK2U+J5y/S05na4zzCHgr90Vx0CKNo68Tt7x6a86TjyDheOYMu8f4cVwZKDTGrOCqeHcct8YrPx0vOBeMwqgEZMbLcce+3tVPjP5eN8RxybBOj1QqkiRf15uulKOD2TT5HiMcqbszIMMXFRmKR5hIEorad4yHOWsm87MDvY2EMz8XSH8yOmfezWeyrhuFIHVG9VireRxurFxt6SQ1Y5P0Mi X-Forefront-Antispam-Report-Untrusted: CIP:40.67.248.234; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:nebula.arm.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230028)(4636009)(376002)(136003)(39860400002)(346002)(396003)(451199021)(36840700001)(46966006)(478600001)(8936002)(8676002)(316002)(41300700001)(82740400003)(6916009)(70206006)(70586007)(40480700001)(81166007)(356005)(186003)(36756003)(2906002)(1076003)(336012)(26005)(426003)(86362001)(83380400001)(47076005)(82310400005)(36860700001)(2616005)(5660300002)(966005)(7696005)(44832011)(36900700001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB9877 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM7EUR03FT007.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 968ad47f-10e5-4bbe-0229-08db401441da X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kUvzGoSh6RV/r04yVSClGlaxj9uQIg1m89lfpARWlbN/We9guRZWA9HLN4qU78DV6Xlpw2ZSWne1vnZCSftHJ77QC219FHDSOJQTP01logylJnoeyKWzeeg82nU2IZ32bHVBuDn8ZIBTPNstSnUYRpgbDnZrssrjtRlDOJuTSo5hXKkhVFsnOovCJw+8Vz8HnfUAeLxiCujeujy49sJJ1rm8RwwkUOz9QFVl3FCQbZmN3lEkiMxNLpAVEh3Ukyxq6oMLnMW5wPYDo2xe1qa7U9iblvuc8APJpgq0LEUppGpRI+A+U66D+YClK3qz7jHsQ3ik3vHBo3as0YCrojAxMPVPPiIGY9ZmXxoLauETWJ7D08TxHUtRDEi/XCsZo2J422+veCOU06Exn3DtO2oWBXwxI4KMfByYkqeifXTQUHYUtH5blENHCfzvfhIl5zeOmEY01wVW6wG4q3YQlEpZk3b4rQqnhKmaHntBTEfAkhkzpM8sacvJGfOdPY5f9DaqZx1Qxf/BB1HXf/Uq3YDhEdL5aSjpfLXZR/AEBkyWyz0FQtBAODK28aWE7HSYrvIs8C4SUuH5APu18R4sdNqwG/U0r03pIJ6oXKrm1minPJFrXU9DaHPj78kjc0MXZ1VUUZOWzhqYZA7c23s8gccMq4b1lxH1iMn/qxXOI5GRelOgBcl9V4xHQCs96FBvkoFY 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:(13230028)(4636009)(376002)(136003)(346002)(396003)(39860400002)(451199021)(40470700004)(36840700001)(46966006)(2906002)(40460700003)(8936002)(8676002)(41300700001)(82740400003)(81166007)(44832011)(5660300002)(82310400005)(36756003)(86362001)(40480700001)(478600001)(36860700001)(2616005)(1076003)(26005)(186003)(966005)(7696005)(70586007)(70206006)(47076005)(6916009)(83380400001)(316002)(426003)(336012); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2023 13:53:25.5982 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c6d44c99-592f-4815-8a45-08db4014481f 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: AM7EUR03FT007.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB6445 X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, 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 <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> From: Luis Machado via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Luis Machado <luis.machado@arm.com> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
[gdb/aarch64] Handle unknown debug architecture versions more gracefully
|
|
Commit Message
Luis Machado
April 18, 2023, 1:53 p.m. UTC
In PR 30340 it was reported that a KVM-based AArch64 system's kernel was returning a debug architecture version of 0 when fetching both the NT_ARM_HW_WATCH and NT_ARM_HW_BREAK register sets. Even though the debug architecture version being reported is invalid, gdb can still make things work by ignoring that information and relying on the counts of hardware watchpoints and hardware breakpoints. This patch makes gdb handle this situation a bit more gracefully by causing gdb to warn when it sees an invalid/unknown debug architecture version, but still allowing gdb to detect the number of hardware watchpoints and hardware breakpoints available. PR tdep/30340 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30340 --- gdb/nat/aarch64-linux-hw-point.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)
Comments
Luis Machado via Gdb-patches <gdb-patches@sourceware.org> writes: > In PR 30340 it was reported that a KVM-based AArch64 system's kernel was > returning a debug architecture version of 0 when fetching both the > NT_ARM_HW_WATCH and NT_ARM_HW_BREAK register sets. > > Even though the debug architecture version being reported is invalid, gdb can > still make things work by ignoring that information and relying on the counts > of hardware watchpoints and hardware breakpoints. > > This patch makes gdb handle this situation a bit more gracefully by causing gdb > to warn when it sees an invalid/unknown debug architecture version, but still > allowing gdb to detect the number of hardware watchpoints and hardware > breakpoints available. > > PR tdep/30340 Apparently we no longer need to include this cookie. Just using the bug url should be enough for this commit to be linked bugzilla. > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30340 > --- > gdb/nat/aarch64-linux-hw-point.c | 24 ++++++++++++++++++++---- > 1 file changed, 20 insertions(+), 4 deletions(-) > > diff --git a/gdb/nat/aarch64-linux-hw-point.c b/gdb/nat/aarch64-linux-hw-point.c > index ccb47cd5aa2..b014d387e1e 100644 > --- a/gdb/nat/aarch64-linux-hw-point.c > +++ b/gdb/nat/aarch64-linux-hw-point.c > @@ -250,10 +250,21 @@ aarch64_linux_get_debug_reg_capacity (int tid) > iov.iov_base = &dreg_state; > iov.iov_len = sizeof (dreg_state); > > + /* It has been reported that under KVM the debug architecture version can > + be reported as 0, which is invalid. But this doesn't mean gdb can't use > + hardware debugging resources. Instead of bailing out, carry on fetching > + the hardware breakpoints/watchpoints count so we can potentially get back > + on track. */ Given my recent comment on pr gdb/30340 you might want to reword the comment a little -- we now understand why we saw 0 in this case. > + > /* Get hardware watchpoint register info. */ > - if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_HW_WATCH, &iov) == 0 > - && compatible_debug_arch (AARCH64_DEBUG_ARCH (dreg_state.dbg_info))) > + if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_HW_WATCH, &iov) == 0) > { > + if (!compatible_debug_arch (AARCH64_DEBUG_ARCH (dreg_state.dbg_info))) > + warning (_("Unknown/Invalid debug architecture version %d.\n" > + "Attempting to fetch the number of hardware watchpoints " > + "available."), > + AARCH64_DEBUG_ARCH (dreg_state.dbg_info)); > + > aarch64_num_wp_regs = AARCH64_DEBUG_NUM_SLOTS (dreg_state.dbg_info); I guess the risk here is that on a later architecture the format of dreg_state might change, in which case reading the wp/bp count might not get the correct result. But in that case we'd print the warning, so when things go wrong later we will have given the user a clue for what the problem might be. So, I think this change seems a reasonable improvement. Reviewed-By: Andrew Burgess <aburgess@redhat.com> Thanks, Andrew > if (aarch64_num_wp_regs > AARCH64_HWP_MAX_NUM) > { > @@ -271,9 +282,14 @@ aarch64_linux_get_debug_reg_capacity (int tid) > } > > /* Get hardware breakpoint register info. */ > - if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_HW_BREAK, &iov) == 0 > - && compatible_debug_arch (AARCH64_DEBUG_ARCH (dreg_state.dbg_info))) > + if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_HW_BREAK, &iov) == 0) > { > + if (!compatible_debug_arch (AARCH64_DEBUG_ARCH (dreg_state.dbg_info))) > + warning (_("Unknown/Invalid debug architecture version %d.\n" > + "Attempting to fetch the number of hardware breakpoints " > + "available."), > + AARCH64_DEBUG_ARCH (dreg_state.dbg_info)); > + > aarch64_num_bp_regs = AARCH64_DEBUG_NUM_SLOTS (dreg_state.dbg_info); > if (aarch64_num_bp_regs > AARCH64_HBP_MAX_NUM) > { > -- > 2.25.1
diff --git a/gdb/nat/aarch64-linux-hw-point.c b/gdb/nat/aarch64-linux-hw-point.c index ccb47cd5aa2..b014d387e1e 100644 --- a/gdb/nat/aarch64-linux-hw-point.c +++ b/gdb/nat/aarch64-linux-hw-point.c @@ -250,10 +250,21 @@ aarch64_linux_get_debug_reg_capacity (int tid) iov.iov_base = &dreg_state; iov.iov_len = sizeof (dreg_state); + /* It has been reported that under KVM the debug architecture version can + be reported as 0, which is invalid. But this doesn't mean gdb can't use + hardware debugging resources. Instead of bailing out, carry on fetching + the hardware breakpoints/watchpoints count so we can potentially get back + on track. */ + /* Get hardware watchpoint register info. */ - if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_HW_WATCH, &iov) == 0 - && compatible_debug_arch (AARCH64_DEBUG_ARCH (dreg_state.dbg_info))) + if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_HW_WATCH, &iov) == 0) { + if (!compatible_debug_arch (AARCH64_DEBUG_ARCH (dreg_state.dbg_info))) + warning (_("Unknown/Invalid debug architecture version %d.\n" + "Attempting to fetch the number of hardware watchpoints " + "available."), + AARCH64_DEBUG_ARCH (dreg_state.dbg_info)); + aarch64_num_wp_regs = AARCH64_DEBUG_NUM_SLOTS (dreg_state.dbg_info); if (aarch64_num_wp_regs > AARCH64_HWP_MAX_NUM) { @@ -271,9 +282,14 @@ aarch64_linux_get_debug_reg_capacity (int tid) } /* Get hardware breakpoint register info. */ - if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_HW_BREAK, &iov) == 0 - && compatible_debug_arch (AARCH64_DEBUG_ARCH (dreg_state.dbg_info))) + if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_HW_BREAK, &iov) == 0) { + if (!compatible_debug_arch (AARCH64_DEBUG_ARCH (dreg_state.dbg_info))) + warning (_("Unknown/Invalid debug architecture version %d.\n" + "Attempting to fetch the number of hardware breakpoints " + "available."), + AARCH64_DEBUG_ARCH (dreg_state.dbg_info)); + aarch64_num_bp_regs = AARCH64_DEBUG_NUM_SLOTS (dreg_state.dbg_info); if (aarch64_num_bp_regs > AARCH64_HBP_MAX_NUM) {