From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2078.outbound.protection.outlook.com [40.107.20.78]) by sourceware.org (Postfix) with ESMTPS id F0B583858D35 for ; Thu, 7 Mar 2024 12:12:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F0B583858D35 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-Filter: OpenARC Filter v1.0.0 sourceware.org F0B583858D35 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.20.78 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1709813532; cv=pass; b=edRK79FCoaE/yq2b2eUr7+PCLCNATEA2sC3uRtM7gf7B1qsQ9G3mdtlrZ6jZRlb+Bcus/tkp8WsOiViY4X+JwotU4IgWx980UZ7ND2t7us3Wqdif1TtGKLEmlmI3AKpMAcEFYGS0Ulfi4nFNf5MV4Ped+SaEyIzmZOck5Xn0CP4= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1709813532; c=relaxed/simple; bh=C1rvZLFgu0WLJtr6M4nMxkSeV4LQp33cVZoIV+/GlU4=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=L8vvwRdV60A7Sy0n9ottVGun3tqQswNDmiWKbVsgzOe4MELGBhA1UA6O8yiGeL8dYN8H5xwWyPkqFD4j+rRSJ/IIOAc3n7EJ4lp2xlOKeSleS8PLqNnJElWlpZn1XSLKwl95atVkBYtuDXcQdvk5xjeLWRkQAYwXhG9aHXI/38U= ARC-Authentication-Results: i=3; server2.sourceware.org ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=oZkueYSFncH6/c/DWNcqrZKonzovA3DZZV1aGIBo+IbZOkiLgRRtnCyeH5uCU6aW38PGvP2JOO7MJYEGZp7FnyLZPae02as64YwpM+WDXki2WekaXokehDBxXfM/VmTa8Qc6YDjRxzHbkFgMXXRpFnimSEyxp//oDbkSpxW/ioISdhjewXv2zLsIGlaQAHcs0bVl026MSVgSCgjxu5kmAX+HcQV3GKue8LO2+7r9aovV/+FIwEnJ2Btxw8IKjXT17KG20lmg+VxCIKyMHB3opESrGWlWQ7ePOAga1CThr+uhB1soP2Tul94E/p6lykvH0OR/RzAt846yYPianWdEfQ== 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=VlpDymUddR6RY3n+NIeoiqcTh2NNlf/dAEFKfEIUuKM=; b=jzRLyhQCpgjVo5HZ+yu5Y7XFqn11ZZM6j6LOKKPhEZ6YlVnMHtxnmD8oqoBUK4n19rIJwkfyT5Tk9mxG2H9Fa04WEzpDxTp9k3ysPDlXA1hX2jmJVYmbABrIFe4sH2l3xJBj/7gjNxuBueGqSS9klveOyTWpCrf79e3TuoRACRAPgaeNBIs6X1fNoBKp6noY9BeUhDErItXJKCJPA3SEUQeCV26d2fF5lowsdHsV2RCeOONH1W3hHs3J8Z2DeqkMMk2jVlJOkxN0d644jgTV8xnrEwkDvvQSKWXkDXxCd/f2i78OoB2xOLpyE/p0huvYurFIMbUAH8WQ7g/rA3vqmQ== 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]) 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=VlpDymUddR6RY3n+NIeoiqcTh2NNlf/dAEFKfEIUuKM=; b=HFeaE7e+msXvGYPCRMHsoTj2j80l6Zv4z14m3FCM2zZvI6NLB9/OO8ZCowrYWtnz8/CPQPzRK/mKEtVXsKpPcbtZUx10lDJB3OfCBxO0o5oc6TZqKdwThvH3zttoO6CHHPRM2m0UiD5WDe4FI9v9zjYcBKAm3LmlaZYEiviB2Kk= Received: from AM4PR07CA0004.eurprd07.prod.outlook.com (2603:10a6:205:1::17) by PA4PR08MB6110.eurprd08.prod.outlook.com (2603:10a6:102:e1::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Thu, 7 Mar 2024 12:12:06 +0000 Received: from AM4PEPF00027A6C.eurprd04.prod.outlook.com (2603:10a6:205:1:cafe::24) by AM4PR07CA0004.outlook.office365.com (2603:10a6:205:1::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24 via Frontend Transport; Thu, 7 Mar 2024 12:12:06 +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 AM4PEPF00027A6C.mail.protection.outlook.com (10.167.16.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.11 via Frontend Transport; Thu, 7 Mar 2024 12:12:05 +0000 Received: ("Tessian outbound 598157ceef91:v276"); Thu, 07 Mar 2024 12:12:05 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: b306b75c101a18e9 X-CR-MTA-TID: 64aa7808 Received: from 90c8e1095f03.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8BDF15ED-65E7-450B-AF85-2C5F0767951F.1; Thu, 07 Mar 2024 12:11:59 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 90c8e1095f03.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 07 Mar 2024 12:11:59 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oBdOfs6bfGyykBovWCe1ziJFFLqS6lcm1Ko3nkVtYC69WXNS8+1xKPyWAe1oB+jtvqJVVE8n+VPe9zvv+d4AroSTafJXT2HFSqkRyjkTxEoOVneV4YFbUzxSS8hnOoaHyOH9SQeQ9s8VSQh8xXvlnC1yL05zVizmkUEcWtYle7n68K613vh6FN8ia50yj21LazO6GHHIYqv42w8Lc27x0TpPO56TyLWd8eSDaT+9UQVLbXy4GQ3shruakA0ez7SDZlypneMnTjVmXEKPzU6rd/8DsJl+2JITv/ywprjNzs9azy5ikyIDuxYTqAxe4058p2eIUiuqU5BVJ4srLxujig== 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=VlpDymUddR6RY3n+NIeoiqcTh2NNlf/dAEFKfEIUuKM=; b=c/4AP6J4AiV+k8l/I1au9ObHEtDqgrAPbzQ8/+HjTxKZdrdpXGZ4kpVaddlbB/9TGV0FGRqz0epGZwllaUWVv7Z9Gx1jDJ7c2aUJhCqVuboJonY7zcjfYeC9CcY75KbgrLqcgYNEM6Vzlab2THolukzISsAjnLURW/lomGK4A3M1NNmL/0JT5hOA6ruq+xrw6sydNdS4ptDXkPJOazzy6dBIgfWs7u5IjeOKx1lwu2SnS4WkhpXDJIxg7FILS/hINyFPlQGBaAlxPD9PLtSqGdEg7LcdzrZhqn0bTelNJYWPLqZDPoGacaRovNIhWOU3Af/5D191qq2Tp4IXvGJRZQ== 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=VlpDymUddR6RY3n+NIeoiqcTh2NNlf/dAEFKfEIUuKM=; b=HFeaE7e+msXvGYPCRMHsoTj2j80l6Zv4z14m3FCM2zZvI6NLB9/OO8ZCowrYWtnz8/CPQPzRK/mKEtVXsKpPcbtZUx10lDJB3OfCBxO0o5oc6TZqKdwThvH3zttoO6CHHPRM2m0UiD5WDe4FI9v9zjYcBKAm3LmlaZYEiviB2Kk= 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 VI0PR08MB10846.eurprd08.prod.outlook.com (2603:10a6:800:211::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Thu, 7 Mar 2024 12:11:55 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::363f:3fc8:fc36:58ed]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::363f:3fc8:fc36:58ed%5]) with mapi id 15.20.7316.037; Thu, 7 Mar 2024 12:11:53 +0000 Message-ID: <6fb49eb9-e480-44b4-9c57-f0e19d43d204@arm.com> Date: Thu, 7 Mar 2024 12:11:47 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] [gdb/tdep] Fix gdb.base/watch-bitfields.exp on aarch64 Content-Language: en-US To: Tom de Vries , gdb-patches@sourceware.org References: <20240220205425.13587-1-tdevries@suse.de> <20240220205425.13587-2-tdevries@suse.de> From: Luis Machado In-Reply-To: <20240220205425.13587-2-tdevries@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: DS7PR05CA0093.namprd05.prod.outlook.com (2603:10b6:8:56::17) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|VI0PR08MB10846:EE_|AM4PEPF00027A6C:EE_|PA4PR08MB6110:EE_ X-MS-Office365-Filtering-Correlation-Id: 213768a5-0f0c-41d2-0440-08dc3e9fce32 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: EOwG+nDSg0V+DFPdX+NsSeH6UIPrajAPJTOrN/6rK8kwbQVQ0afYhEZceLEWgQTFpy1fvib0eZTn7FhxOe5jdkj8r+dNrsm6Tk3rWxAX8VjpQVTSy3Tni2fdRy8YSyQtuO9x7obRXcxsdk2tUTBY00T5htpPVdKoStC3BXhVphNntYDAfu43ZQTzQeHN7hUvKx85jSMNPF2aeOrB3O80jiPd9eKij8iCW/CcQStlyUP+XhQ8TYgY9926Vy6I9AYFDyQIMesV8UtqsO4r0mF+qQQ44m8yyXpdt3E4zFICErlFyOvHwKE5iBAofHtTEeNQMwS2KG6lJ/hvvvoq+W+6vzGl6sLNBCaVlpchPjWYl4WrZMfIO7F9bbow4lNaFS3/S2Fwj7n/ONEJN9iKi7fznIZiGL6ab65uvVmVGWSlCUUZCr+RbCb9NVHR9zS6mBQNbjmDlraN4DC/R72z8Vm9VEtKUHaGaZC4HBdTcKy/mLHUeogzV8QB7A606WY3F1hoEKhRyHWkZ+cbh7XvpMoR4NrUo1AMWA0Pbu/RSSON6PKxr2mU5X4ex8PYGkv9IHBDaEPBuvu4uTBBE8Wc3nONlUaFe/0e1M7TE34eJcDMf6w= 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:(13230031)(376005);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB10846 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: AM4PEPF00027A6C.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 9a94844f-29dd-49a0-71b7-08dc3e9fc652 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xg8MM6vAxYUxrAuT1uDMHnYzA0V+Yb0ViJ1dZ1Jt81KJZG4HrSeYioo/W8koIXMmO4C8H+vXcHB4B5Gy1w440bdKa8loVZEmEwVeuh0/CHFz1bwcUu+QeNy2kzotqAY3myJZRx/zsNCACf8qzp2Fpza7ONzn8aXx2j/eLmtJtcPcGXQyWBkQRqQO+PaxrHozCQzYs4OGJyQ9nnuQXJIZQXiBAP2zqR8NNLGmcMFSgyrylgFuvLB1zR1gdHSDlBjRkRuesA6ZV6vZJaA1Loa4ZfQbYhOcEep+8enBV23jC07OYsE1yV5cQdLn7qmrIsAvsztTEmOETnVmSB+oOyfUmpV4x7RA6HRcsBIIpZZLk8qW14v3kzBap2+K3FsmCxd6Kot/PRaxcSeJAzO51OsIJkjW7K/blYcyCya3eHJci6k8/kb/U0f8BFMdBk/C8G2s9B1m07I9l07opfjwDSdvgnXYuZCKn0VWkChX27jsR2G/3Yp7WXMNAnytG7RJAIWh2pjuehzqks+rb/VvSjdFcqoU/XL3Zh/bYzM8FHhBgglIzng3j8/cbFxxUX4OUpHUSedbwohvsOZVssAkjuB2dUGNu0UgrKIm81Py2DNdUAn0eiNaQPvO1qCFFs2H4iWuIPPJRRCnatkIOdl5ILWHLBhYJDMeXk8UWVGzDgBynpReg5SKwdyEMv85JO3ao1tSAywq68hMDZ0lYV0LjNtCzA== 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:(13230031)(82310400014)(376005)(36860700004);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2024 12:12:05.9093 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 213768a5-0f0c-41d2-0440-08dc3e9fce32 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: AM4PEPF00027A6C.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6110 X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,GIT_PATCH_0,KAM_DMARC_NONE,KAM_NUMSUBJECT,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 List-Id: Hi Tom, On 2/20/24 20:54, Tom de Vries wrote: > On aarch64-linux, with test-case gdb.base/watch-bitfields.exp I run into: > ... > (gdb) continue^M > Continuing.^M > ^M > Hardware watchpoint 2: -location q.a^M > ^M > Old value = 1^M > New value = 0^M > main () at watch-bitfields.c:42^M > 42 q.h--;^M > (gdb) FAIL: $exp: -location watch against bitfields: q.e: 0->5: continue > ... Unfortunately I don't see the same failure on a graviton (aarch64). It is usually how these hardware watchpoint issues go. Things behave differently depending on the setup you have, since the reported trap address may be different. > > In a minimal form, if we step past line 37 which sets q.e, and we have a > watchpoint set on q.e, it triggers: > ... > $ gdb -q -batch watch-bitfields -ex "b 37" -ex run -ex "watch q.e" -ex step > Breakpoint 1 at 0x410204: file watch-bitfields.c, line 37. > > Breakpoint 1, main () at watch-bitfields.c:37 > 37 q.e = 5; > Hardware watchpoint 2: q.e > > Hardware watchpoint 2: q.e > > Old value = 0 > New value = 5 > main () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c:38 > 38 q.f = 6; > ... > > However, if we set in addition a watchpoint on q.a, the watchpoint on q.e > doesn't trigger. > > How does this happen? > > Bitfield q.a is just bit 0 of byte 0, and bitfield q.e is bit 4..7 of byte 1 > and bit 1 of byte 2. So, watch q.a should watch byte 0, and watch q.e should > watch bytes 1 and 2. > > Using "maint set show-debug-regs on" (and some more detailed debug prints) we > get: > ... > WP2: addr=0x440028 (orig=0x440029), ctrl=0x000000d5, ref.count=1 > ctrl: enabled=1, offset=1, len=2 > WP3: addr=0x440028 (orig=0x440028), ctrl=0x00000035, ref.count=1 > ctrl: enabled=1, offset=0, len=1 > ... > which matches that. > > When executing line 37, a hardware watchpoint trap triggers and we hit > aarch64_stopped_data_address with addr_trap == 0x440028: > ... > (gdb) p /x addr_trap > $1 = 0x440028 > .... > and since the loop in aarch64_stopped_data_address walks backward, we check > WP3 first, which matches, and consequently target_stopped_by_watchpoint > returns true in watchpoints_triggered. > > Likewise for target_stopped_data_address, which also returns addr == 0x440028. > Watchpoints_triggered matches watchpoint q.a to that address, and sets > watch_triggered_yes. > > However, subsequently the value of q.a is checked, and it's the same value as > before (becase the insn in line 37 didn't change q.a), so the watchpoint > hardware trap is not reported to the user. > > The problem originates from that fact that aarch64_stopped_data_address picked > WP3 instead of WP2. > > There's something we can do about this. In the example above, both > target_stopped_by_watchpoint and target_stopped_data_address returned true. > Instead we can return true in target_stopped_by_watchpoint but false in > target_stopped_data_address. This lets watchpoints_triggered known that a > watchpoint was triggered, but we don't know where, and both watchpoints > get set to watch_triggered_unknown. > > Subsequently, the values of both q.a and q.e are checked, and since q.e is not > the same value as before, the watchpoint hardware trap is reported to the user. > > Note that this works well for regular (write) watchpoints (watch command), but > not for read watchpoints (rwatch command), because for those no value is > checked. Likewise for access watchpoints (awatch command). > > So, fix this by: > - passing a nullptr in aarch64_fbsd_nat_target::stopped_by_watchpoint and > aarch64_linux_nat_target::stopped_by_watchpoint to make clear we're not > interested in the stop address, > - introducing a two-phase approach in aarch64_stopped_data_address, where: > - phase one handles access and read watchpoints, as before, and > - phase two handles write watchpoints, where multiple matches cause: > - return true if addr_p == null, and > - return false if addr_p != null. To make sure I understand the approach, does the case where we have a write hardware watchpoint and addr_p != null (thus returning false for aarch64_stopped_data_address) mean we don't report any stopped data addresses, but we will still report a hardware watchpoint trigger internally and remove said hardware watchpoints before attempting to step-over them? I think one of the more critical issues is gdb getting stuck on hardware watchpoint triggers it is not noticing, thus causing an endless loop of trying to step-over them and failing. > > Tested on aarch64-linux. > --- > gdb/aarch64-fbsd-nat.c | 4 +- > gdb/aarch64-linux-nat.c | 4 +- > gdb/aarch64-nat.c | 133 ++++++++++++++++++++++++++----------- > gdb/nat/aarch64-hw-point.c | 25 +++++++ > gdb/nat/aarch64-hw-point.h | 2 + > 5 files changed, 123 insertions(+), 45 deletions(-) > > diff --git a/gdb/aarch64-fbsd-nat.c b/gdb/aarch64-fbsd-nat.c > index d7aa819023b..89ed12bb8e5 100644 > --- a/gdb/aarch64-fbsd-nat.c > +++ b/gdb/aarch64-fbsd-nat.c > @@ -164,9 +164,7 @@ aarch64_fbsd_nat_target::stopped_data_address (CORE_ADDR *addr_p) > bool > aarch64_fbsd_nat_target::stopped_by_watchpoint () > { > - CORE_ADDR addr; > - > - return stopped_data_address (&addr); > + return stopped_data_address (nullptr); > } > > /* Implement the "stopped_by_hw_breakpoint" target_ops method. */ > diff --git a/gdb/aarch64-linux-nat.c b/gdb/aarch64-linux-nat.c > index 11a41e1afae..7dc53ff9e91 100644 > --- a/gdb/aarch64-linux-nat.c > +++ b/gdb/aarch64-linux-nat.c > @@ -972,9 +972,7 @@ aarch64_linux_nat_target::stopped_data_address (CORE_ADDR *addr_p) > bool > aarch64_linux_nat_target::stopped_by_watchpoint () > { > - CORE_ADDR addr; > - > - return stopped_data_address (&addr); > + return stopped_data_address (nullptr); > } > > /* Implement the "can_do_single_step" target_ops method. */ > diff --git a/gdb/aarch64-nat.c b/gdb/aarch64-nat.c > index 5d7d2be2827..9e859cf28cc 100644 > --- a/gdb/aarch64-nat.c > +++ b/gdb/aarch64-nat.c > @@ -231,47 +231,102 @@ bool > aarch64_stopped_data_address (const struct aarch64_debug_reg_state *state, > CORE_ADDR addr_trap, CORE_ADDR *addr_p) > { > - int i; > - > - for (i = aarch64_num_wp_regs - 1; i >= 0; --i) > - { > - const unsigned int offset > - = aarch64_watchpoint_offset (state->dr_ctrl_wp[i]); > - const unsigned int len = aarch64_watchpoint_length (state->dr_ctrl_wp[i]); > - const CORE_ADDR addr_watch = state->dr_addr_wp[i] + offset; > - const CORE_ADDR addr_watch_aligned > - = align_down (state->dr_addr_wp[i], 16); > - const CORE_ADDR addr_orig = state->dr_addr_orig_wp[i]; > - > - if (state->dr_ref_count_wp[i] > - && DR_CONTROL_ENABLED (state->dr_ctrl_wp[i]) > - && addr_trap >= addr_watch_aligned > - && addr_trap < addr_watch + len) > - { > - /* ADDR_TRAP reports the first address of the memory range > - accessed by the CPU, regardless of what was the memory > - range watched. Thus, a large CPU access that straddles > - the ADDR_WATCH..ADDR_WATCH+LEN range may result in an > - ADDR_TRAP that is lower than the > - ADDR_WATCH..ADDR_WATCH+LEN range. E.g.: > - > - addr: | 4 | 5 | 6 | 7 | 8 | > - |---- range watched ----| > - |----------- range accessed ------------| > - > - In this case, ADDR_TRAP will be 4. > - > - To match a watchpoint known to GDB core, we must never > - report *ADDR_P outside of any ADDR_WATCH..ADDR_WATCH+LEN > - range. ADDR_WATCH <= ADDR_TRAP < ADDR_ORIG is a false > - positive on kernels older than 4.10. See PR > - external/20207. */ > + bool found = false; > + for (int phase = 0; phase <= 1; ++phase) > + for (int i = aarch64_num_wp_regs - 1; i >= 0; --i) > + { > + if (!(state->dr_ref_count_wp[i] > + && DR_CONTROL_ENABLED (state->dr_ctrl_wp[i]))) > + { > + /* Watchpoint disabled. */ > + continue; > + } > + > + const enum target_hw_bp_type type > + = aarch64_watchpoint_type (state->dr_ctrl_wp[i]); > + if (type == hw_execute) > + { > + /* Watchpoint disabled. */ > + continue; > + } > + > + if (phase == 0) > + { > + /* Phase 0: No hw_write. */ > + if (type == hw_write) > + continue; > + } > + else > + { > + /* Phase 1: Only hw_write. */ > + if (type != hw_write) > + continue; > + } > + > + const unsigned int offset > + = aarch64_watchpoint_offset (state->dr_ctrl_wp[i]); > + const unsigned int len > + = aarch64_watchpoint_length (state->dr_ctrl_wp[i]); > + const CORE_ADDR addr_watch = state->dr_addr_wp[i] + offset; > + const CORE_ADDR addr_watch_aligned > + = align_down (state->dr_addr_wp[i], 16); > + const CORE_ADDR addr_orig = state->dr_addr_orig_wp[i]; > + > + /* ADDR_TRAP reports the first address of the memory range > + accessed by the CPU, regardless of what was the memory > + range watched. Thus, a large CPU access that straddles > + the ADDR_WATCH..ADDR_WATCH+LEN range may result in an > + ADDR_TRAP that is lower than the > + ADDR_WATCH..ADDR_WATCH+LEN range. E.g.: > + > + addr: | 4 | 5 | 6 | 7 | 8 | > + |---- range watched ----| > + |----------- range accessed ------------| > + > + In this case, ADDR_TRAP will be 4. */ > + if (!(addr_trap >= addr_watch_aligned > + && addr_trap < addr_watch + len)) > + { > + /* Not a match. */ > + continue; > + } > + > + /* To match a watchpoint known to GDB core, we must never > + report *ADDR_P outside of any ADDR_WATCH..ADDR_WATCH+LEN > + range. ADDR_WATCH <= ADDR_TRAP < ADDR_ORIG is a false > + positive on kernels older than 4.10. See PR > + external/20207. */ > + if (addr_p != nullptr) > *addr_p = addr_orig; > - return true; > - } > - } > > - return false; > + if (phase == 0) > + { > + /* Phase 0: Return first match. */ > + return true; > + } > + > + /* Phase 1. */ > + if (addr_p == nullptr) > + { > + /* First match, and we don't need to report an address. No need > + to look for other matches. */ > + return true; > + } > + > + if (!found) > + { > + /* First match, and we need to report an address. Look for other > + matches. */ > + found = true; > + continue; > + } > + > + /* More that one match, and we need to return an address. No need to s/More that/More than > + look for further matches. */ > + return false; > + } > + > + return found; > } > > /* Define AArch64 maintenance commands. */ > diff --git a/gdb/nat/aarch64-hw-point.c b/gdb/nat/aarch64-hw-point.c > index 04674dea2a6..08fd230b71f 100644 > --- a/gdb/nat/aarch64-hw-point.c > +++ b/gdb/nat/aarch64-hw-point.c > @@ -73,6 +73,31 @@ aarch64_watchpoint_length (unsigned int ctrl) > return retval; > } > > +/* Utility function that returns the type of a watchpoint according to the > + content of a hardware debug control register CTRL. */ > + > +enum target_hw_bp_type > +aarch64_watchpoint_type (unsigned int ctrl) > +{ > + unsigned int type = DR_CONTROL_TYPE (ctrl); > + > + switch (type) > + { > + case 1: > + return hw_read; > + case 2: > + return hw_write; > + case 3: > + return hw_access; > + case 0: > + /* Reserved for a watchpoint. It must behave as if the watchpoint is > + disabled. */ > + return hw_execute; > + default: > + gdb_assert_not_reached (""); > + } > +} > + > /* Given the hardware breakpoint or watchpoint type TYPE and its > length LEN, return the expected encoding for a hardware > breakpoint/watchpoint control register. */ > diff --git a/gdb/nat/aarch64-hw-point.h b/gdb/nat/aarch64-hw-point.h > index 70f71db7520..bdcca932e57 100644 > --- a/gdb/nat/aarch64-hw-point.h > +++ b/gdb/nat/aarch64-hw-point.h > @@ -73,6 +73,7 @@ > > #define DR_CONTROL_ENABLED(ctrl) (((ctrl) & 0x1) == 1) > #define DR_CONTROL_MASK(ctrl) (((ctrl) >> 5) & 0xff) > +#define DR_CONTROL_TYPE(ctrl) (((ctrl) >> 3) & 0x3) > > /* Structure for managing the hardware breakpoint/watchpoint resources. > DR_ADDR_* stores the address, DR_CTRL_* stores the control register > @@ -107,6 +108,7 @@ void aarch64_notify_debug_reg_change (ptid_t ptid, int is_watchpoint, > > unsigned int aarch64_watchpoint_offset (unsigned int ctrl); > unsigned int aarch64_watchpoint_length (unsigned int ctrl); > +enum target_hw_bp_type aarch64_watchpoint_type (unsigned int ctrl); > > int aarch64_handle_breakpoint (enum target_hw_bp_type type, CORE_ADDR addr, > int len, int is_insert, ptid_t ptid, I think this is a reasonable workaround for this situation you describe. Testing on my end doesn't seem to cause any issues, so I think this is OK. Out of curiosity, what is your aarch64 setup where you can reproduce this failure? Approved-By: Luis Machado