From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-AM7-obe.outbound.protection.outlook.com (mail-am7eur03on2084.outbound.protection.outlook.com [40.107.105.84]) by sourceware.org (Postfix) with ESMTPS id 91AAF3858D35 for ; Mon, 8 Jan 2024 12:27:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 91AAF3858D35 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 91AAF3858D35 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.105.84 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1704716848; cv=pass; b=lV9TOUcRLOy4Ql2QBjA4tBtEUkuGQmSoZSkBaKRS7kxvn1rwmj7Ie/Ryd+utgcb5sIAeB5tpVVVCz/YZGMu2RqU3sthvL/12gf8uQRkOee+1hZyXgbqOPM7l1G8O1Vq45GkOyHSxb/4WONk1vY5TkAgA0PfE3/sbSoNY/OWEz0M= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1704716848; c=relaxed/simple; bh=9vWAAU7NMLvwRiEKeMoW0PnQbafsuckZGzU2N047El4=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=W0Me5ziizi7ADPfVjX5NBlDarW6SvgghVcmgEYnHS6X2Vfdl22nrYa5VyNLsZQA4cCUxUR6BXg+S17BJjD1qE4MwGQ2rY1jvkl8hOgxdbcr+SRLP1EPUtwHBpU2qRv7hp6fT03UIOCinwhX8LgAR4mPg84k27H0ulbRHPjXvx/E= ARC-Authentication-Results: i=3; server2.sourceware.org ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=lTzIf0HvuCezA7HmOVLR2bW70Qkmy9i9e0+NpxQIO8rJWab4bk7erGp+b3llOjLC8o22QjtQRTdnVRQT07sKwLE8pDYi90Ub/FXxwb6Ay63kEr+CCpwy1yP2aL3SVVzNlvh7fg4tiH7DmLNF71sPhO4zqrGHAvczo8t724PFc+npgHMHXdiLsX5VPbwGrvrBZNqLIE5RNoLwZ/l3fgnFdLs9CigZbANfpba9Jukd5e4JhfdR6PBa7UEyf1LmEf5dvXpejeizZCeR1qYCFS8+i2oQQasAW9s9puSV1Xf1yL0AtMw4VGC/NR6Tzoh3mRfq/np2FPfftACB+7523udQFQ== 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=p9hKqa2VDhcix5RDsO2BsrdmlkhNYcSYME6wxa5cz8c=; b=jyov6Z1JBi/GCpvPtRIYZ/YJ7/o/IgL/AXz33GFRFrkRltAqjeS7TnJ3q9VjwANnrmHBTJCvfgveNiZnYhfCEfKhwkMNJnupo8F7GASBWH2RMHhTx+rFMjzDCkBIL59FG2IzF29ZZtGFkguSjtgXWi/FV7XhsdJ/MHY21Hc03GhDa6jkK7eHoIo72b1o9odTvfcvaYypNthu6IOxRpBeOHBCh35k5P0bS9zrF3+WlQoB76cwSG55lj5H5MESruv9Z7oumYlQWr77J2sAknek4nkqI+WSMYMXSemKQOoq0W9Y3z7rOsxoLEXXhNoqqOPWufATGDWwpoB5+sL3ZZ4UgQ== 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=p9hKqa2VDhcix5RDsO2BsrdmlkhNYcSYME6wxa5cz8c=; b=i28PPKKh4H8MstmSnJUmXtltM/qYxyKCJHUhKDhUKA4N09k/WbdE4r28lHDCd34JwIFK0rNnoeyznKb7ix4nECLgfmR7QrSfh9wSInJUX9MWxIQQFw2ffW4TSybB+kTzcI1YazBjqYcGupxFQXfZKAzrRhUOKkTAOsZv+uHitvg= Received: from DU2PR04CA0302.eurprd04.prod.outlook.com (2603:10a6:10:2b5::7) by DBBPR08MB6057.eurprd08.prod.outlook.com (2603:10a6:10:1f5::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7159.21; Mon, 8 Jan 2024 12:27:21 +0000 Received: from DB1PEPF0003922D.eurprd03.prod.outlook.com (2603:10a6:10:2b5:cafe::db) by DU2PR04CA0302.outlook.office365.com (2603:10a6:10:2b5::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7159.21 via Frontend Transport; Mon, 8 Jan 2024 12:27:21 +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 DB1PEPF0003922D.mail.protection.outlook.com (10.167.8.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.13 via Frontend Transport; Mon, 8 Jan 2024 12:27:21 +0000 Received: ("Tessian outbound 52fd419df13e:v239"); Mon, 08 Jan 2024 12:27:21 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 1ca5800ef8dd6421 X-CR-MTA-TID: 64aa7808 Received: from 9cac77218964.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A6E92044-EF61-455C-A9C5-DB8A232C1016.1; Mon, 08 Jan 2024 12:27:15 +0000 Received: from EUR03-AM7-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 9cac77218964.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 08 Jan 2024 12:27:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U7aNAegvALJD3kP86tsQtmqAXQ/UrGbS3oLBAPAzAS8S4ny9xDhRi/J5U1inYfl+B0Zxq4Dl8+YUaNaeksZKl8GIQp57O17q53xFl+mMeuZPDNEbO42oCzZ1kdxAoBMAXi3fuQdymIS/gOHJvT7pc+vWm2RKWccWOGLc7DruQAZuPDCB7aihrQixZ0DoOBaI8t/lJTRyG4J3KNtd2bJ1C8lWC2vz1szCV2p/s/gV/smJp+gQGHk4Qzg/3X2FBKWM74QCAh3IEJ9CGbsmWbsESQ5zfJbw3YDeaogBTeSv4W4YusudnRO5s2Dm0dpoNR5oP0U0pIQhFaW3WmwxEMVPdg== 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=p9hKqa2VDhcix5RDsO2BsrdmlkhNYcSYME6wxa5cz8c=; b=WxHd06TrP6NJyIj08332QweYdr3BkP0TyR3XmUI6Rgy1w3KDjy/8b251eNmyG+RqdhjkeZF9VJYfLVi6qEgX8N147A1151cces9QUfNmtVbw9ZECozZCXWC03CSQqiA9bPrNhMAI3Ehm1T40EYbe2QAq12een1tdDqFwznHImK7L8lPb0Fis4ciHAzx/N9A7uahfm0GSEGeHkE2wIYHmqjGqLYhBNGz3CVXp4s5BW8Mtyc+pyNnuPWbmMqkIc4eq4aYrvEeZnN8fNwrH2oV+f6zaJCsVAIZz7QtPl7wN4U9Fz80fCM8Le1hUVpBcwj0/ndKsisF3yGn/0tH+Z0So8Q== 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=p9hKqa2VDhcix5RDsO2BsrdmlkhNYcSYME6wxa5cz8c=; b=i28PPKKh4H8MstmSnJUmXtltM/qYxyKCJHUhKDhUKA4N09k/WbdE4r28lHDCd34JwIFK0rNnoeyznKb7ix4nECLgfmR7QrSfh9wSInJUX9MWxIQQFw2ffW4TSybB+kTzcI1YazBjqYcGupxFQXfZKAzrRhUOKkTAOsZv+uHitvg= 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 AS2PR08MB9125.eurprd08.prod.outlook.com (2603:10a6:20b:5e5::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7159.21; Mon, 8 Jan 2024 12:27:10 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::935e:b3a1:b0fd:99ac]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::935e:b3a1:b0fd:99ac%4]) with mapi id 15.20.7159.020; Mon, 8 Jan 2024 12:27:10 +0000 Message-ID: <36f17aa1-72a5-4b57-a15d-efce90cf8b2d@arm.com> Date: Mon, 8 Jan 2024 12:27:08 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] Fix missing watchpoint hits/endless loop To: Tom de Vries , gdb-patches@sourceware.org References: <20240105150734.5287-1-tdevries@suse.de> Content-Language: en-US From: Luis Machado In-Reply-To: <20240105150734.5287-1-tdevries@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0255.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37c::20) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|AS2PR08MB9125:EE_|DB1PEPF0003922D:EE_|DBBPR08MB6057:EE_ X-MS-Office365-Filtering-Correlation-Id: 92095479-95fe-41f7-6e02-08dc10452997 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: 7B1UNZLgOsh9C9ec9FcYcO5N+Ry0G0sk6kvhBthLcNl2F6KsE7S2+ovqogQQ0NFVYqnMQEdmj7Q8KwqrqRnLrZAsYD197fGKXng++5jLrBhjPfXhBzMXWfConAKUh8JZ7vQMgbU8ubtx8oTHDLoSYcrn1FQfjhCOCHc4aK/Lqpzgoch2kdcZe0Czf0bSJKi4xj1P3mR2uHJk49Vcp3ORHETvSo/BLN9D7Vpa/rJ1Pxb/I1xdfutzr3gdxx7wFXxdQXRS/CuIsKIf2WjFlLDDLDphS3xU8EU31wL9b5XwGvzjv27ShZTrKGoX2vCzp+B9QExXlrxE4L9PLnZ91bzYne9dmg9yhczrFGqwvwtMHa4+WYT6g3yuVAoTl7B0LNnmcLHza69xlzU6Cf/4B7hmsrO9jyI8i2GsiaDUrkePLtAkgRJZbEgMoozIknoUVDCyowb23EiRSi1mqGNE2GzBx5NntraBPZW3oq3rbH/I635HUzXFKXIWqUgePnilxRGjtjCWpDFQiiLyRyKpVHWdAHThM12bgJiHi44IxGWY8XDr6PdSErSV29VIz+XTvKH1i9b2v0c5NW6/x8S+WdCDzcLIPf+8nJVtO585sZp4MsCCfzTVUImiLSroDotnP5+i 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)(39860400002)(346002)(136003)(366004)(376002)(396003)(230922051799003)(186009)(451199024)(1800799012)(64100799003)(31686004)(84970400001)(26005)(53546011)(2616005)(6512007)(6506007)(478600001)(6486002)(966005)(38100700002)(86362001)(36756003)(31696002)(5660300002)(30864003)(2906002)(41300700001)(83380400001)(66946007)(66556008)(66476007)(316002)(8676002)(8936002)(44832011)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9125 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: DB1PEPF0003922D.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 616ad6a5-3974-47fa-38bd-08dc104522d3 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kUeglIw3YvIlNexRZ0QjnutpKf/C0lKmFjf3CevI7zTsqqkV3vqosii28hPwkOugYTuXOtDq6Uqp/efsAIV7+HVE4sMIzENIGrj1QWajlpDsGN6DJDxWQFkf57PySdhU3JfgtjbAFK8XasqLUHv4DaXBp882IQIRdiq4vzjIuCdQ5csg7NtOBFDlpkPqYn+KA6g22H8Ouos5xNTqblODYOYc5wyUrcwyMXxpjyw6vmzWwKE8AnTuHv0y/nRIDN7uo3/fFiKSO6kQy/8W/ONW2DbvMdqqy7RIFhapA1AdRMpO36RciykHDCO5lXHpeXXqLHo046oWoygG6AMKFfbqOIsYj68AmoQV/MBIWOW7+qWOO0lQ/21usEoDnl1Ldzvk0P5xQXfVOJG+DA6sVAnka94AWAO3U4HGjbHV4xBWFOhwB4IgbuvmU4NLmYxc5ZRVS5x1OEemse1CRR9hfSmnHFuFlh4mdKf0sMLWc3kbzTPYka0B9yBkzbsHindRW5uzX5XQM2tuTrgVxuW4GywP7QnUK+/21Tv7CcdyoYYsZFPrZ9eDOJILdY4YL/2cEZGjnTDjoTydCl4LCt4w4P3nd6sJlccHlACq6CyXtl+5OTrMi9s5S+rYS+1IwivoWe6vkGAJydFArzBFysba1MCrv4llP57ERe5rOoo3k9iNvuqszOHPwXKqYe69563+TlZcs6Or8byjrW4u7lf7kDpBKCIgKQpmtbIkY8cx2eyGd8Iow/T7Wmfef/dUtqYSc9Ag 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)(4636009)(136003)(376002)(396003)(346002)(39860400002)(230922051799003)(1800799012)(451199024)(82310400011)(64100799003)(186009)(36840700001)(46966006)(40470700004)(26005)(966005)(6486002)(47076005)(53546011)(2616005)(336012)(478600001)(6506007)(6512007)(5660300002)(36860700001)(83380400001)(30864003)(2906002)(41300700001)(70206006)(316002)(8936002)(8676002)(44832011)(70586007)(82740400003)(31696002)(86362001)(36756003)(356005)(81166007)(84970400001)(40460700003)(31686004)(40480700001)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2024 12:27:21.6345 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 92095479-95fe-41f7-6e02-08dc10452997 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: DB1PEPF0003922D.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6057 X-Spam-Status: No, score=-11.7 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 List-Id: Hi Tom, Thanks for refreshing this patch. As I hinted on IRC, back then I ended up deciding not to pursue this approach further. Though it does address some of the potential failures, it is a bit convoluted and poses a fairly significant maintenance burden (we need to explicitly identify instructions, so we will always be behind), including the risk of producing false positives. For SVE/SME, there are also predicated accesses, which means an intruction may read/write a discontiguous range of bytes depending on the predicate mask. That is trickier to handle. The nature of hardware watchpoint detection on aarch64 means the triggering behavior is dependent on a particular CPU spec, in a way that is hard for userspace to predict reliably. Hopefully in the future this situation will improve for userspace. The kernel folks are aware of it. Meanwhile, given the above restrictions (and potentially restrictions of other architectures), we could teach gdb about imprecise hardware watchpoint triggers. Something that would allow gdb to tell userspace that we know a hardware watchpoint has triggered, but we don't know exactly for what range and what happened. At least this would prevent certain situations where gdb is simply stuck trying to skip over unskippable hardware watchpoints, because it can't tell what happened and ended up with a generic SIGTRAP. Thoughts? On 1/5/24 15:07, Tom de Vries wrote: > From: Luis Machado > > Updates on v3: > > - Rebased to current trunk (v2 applied cleanly on gdb-12-branch). > - Should also work on fbsd, though I haven't tested it. > - Dropped gdbserver part (should be possible, I'm just not sure yet where to > move aarch64_stopped_data_address such that it's accessible from gdbserver). > - No attempt made to address any review remarks on v2. > https://inbox.sourceware.org/gdb-patches/D2AC3C31-5EEE-4BCA-8D75-7CEDFA75F540@arm.com/ > > Updates on v2: > > - Handle more types of load/store instructions, including a catch all > for SVE load/store instructions. > > -- > > I ran into a situation where a hardware watchpoint hit is not detected > correctly, misleading GDB into thinking it was a delayed breakpoint hit. > > The problem is that hardware watchpoints are not skippable on AArch64, so > that makes GDB loop endlessly trying to run past the instruction. > > The most obvious case where this happens is when the load/store pair > instructions access 16 bytes of memory. > > Suppose we have a stp instruction that will write a couple 64-bit registers > to address 0x10 (stp x3,x4 [x2]). It will write data from 0x10 up to 0x20. > > Now suppose a write watchpoint is created to monitor memory address 0x18, > which is the start of the second register write. It can have whatever length, > but let's assume it has length 8. > > When we execute that stp instruction, it will trap and the reported stopped > data address from the kernel will be 0x10 (the beginning of the memory range > accessed by the instruction). > > The current code won't be able to detect a valid trigger because it assumes an > alignment of 8 bytes for the watchpoint address. Forcing that kind of alignment > won't be enough to detect a 16-byte access if the trap address falls outside of > the 8-byte alignment window. We need to know how many bytes the instruction > will access, but we won't have that data unless we go parsing instructions. > > Another issue with the current code seems to be that it assumes the accesses > will always be 8 bytes in size, since it wants to align the watchpoint address > to that particular boundary. This leads to problems when we have unaligned > addresses and unaligned watchpoints. > > For example, suppose we have a str instruction storing 8 bytes to memory > address 0xf. Now suppose we have a write watchpoint at address 0x16, > monitoring 8 bytes. > > The trap address will be 0xf, but forcing 0x16 to 8-byte alignment yields > 0x10, and so GDB doesn't think this is a watchpoint hit. > > I believe you can trigger the same problem with smaller memory accesses, > except one that accesses a single byte. > > In order to cover most of the cases correctly, we parse the load/store > instructions and detect how many bytes they're accessing. That will give us > enough information to tell if a hardware watchpoint triggered or not. > > The SVE load/store support is only a placeholder for now, as we need to > parse the instructions and use the variable length to determine the memory > access size (planned for the future). > > The patch also fixes these two failures in the testsuite: > > FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout) > FAIL: gdb.base/watchpoint-unaligned.exp: size8twice write > > Regression tested (v2) on aarch64-linux Ubuntu/20.04 and Ubuntu/18.04. > Regression tested (v3) on aarch64-linux fedora 39. > > I also used a very slow aarch64 hardware watchpoint stress test to validate > the v2 patch, but I don't think that particular test should be included in the > testsuite. It takes quite a while to run (20+ minutes), and shouldn't be > required unless we know there are problems with hardware watchpoint handling. > > PR tdep/29423 > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423 > --- > gdb/aarch64-fbsd-nat.c | 7 +- > gdb/aarch64-linux-nat.c | 7 +- > gdb/aarch64-nat.c | 268 ++++++++++++++++++++++++++++++++++++++-- > gdb/aarch64-nat.h | 3 +- > 4 files changed, 273 insertions(+), 12 deletions(-) > > diff --git a/gdb/aarch64-fbsd-nat.c b/gdb/aarch64-fbsd-nat.c > index 38fb093f139..39162fe3bb0 100644 > --- a/gdb/aarch64-fbsd-nat.c > +++ b/gdb/aarch64-fbsd-nat.c > @@ -154,9 +154,14 @@ aarch64_fbsd_nat_target::stopped_data_address (CORE_ADDR *addr_p) > > const CORE_ADDR addr_trap = (CORE_ADDR) siginfo.si_addr; > > + struct regcache *regs = get_thread_regcache (this, inferior_ptid); > + CORE_ADDR trigger_pc = regcache_read_pc (regs); > + uint32_t insn; > + read_memory (trigger_pc, (gdb_byte *) &insn, 4); > + > /* Check if the address matches any watched address. */ > state = aarch64_get_debug_reg_state (inferior_ptid.pid ()); > - return aarch64_stopped_data_address (state, addr_trap, addr_p); > + return aarch64_stopped_data_address (state, insn, addr_trap, addr_p); > } > > /* Implement the "stopped_by_watchpoint" target_ops method. */ > diff --git a/gdb/aarch64-linux-nat.c b/gdb/aarch64-linux-nat.c > index 5b4e3c2bde1..5494bb07517 100644 > --- a/gdb/aarch64-linux-nat.c > +++ b/gdb/aarch64-linux-nat.c > @@ -962,9 +962,14 @@ aarch64_linux_nat_target::stopped_data_address (CORE_ADDR *addr_p) > const CORE_ADDR addr_trap > = gdbarch_remove_non_address_bits (gdbarch, (CORE_ADDR) siginfo.si_addr); > > + struct regcache *regs = get_thread_regcache (this, inferior_ptid); > + CORE_ADDR trigger_pc = regcache_read_pc (regs); > + uint32_t insn; > + read_memory (trigger_pc, (gdb_byte *) &insn, 4); > + > /* Check if the address matches any watched address. */ > state = aarch64_get_debug_reg_state (inferior_ptid.pid ()); > - return aarch64_stopped_data_address (state, addr_trap, addr_p); > + return aarch64_stopped_data_address (state, insn, addr_trap, addr_p); > } > > /* Implement the "stopped_by_watchpoint" target_ops method. */ > diff --git a/gdb/aarch64-nat.c b/gdb/aarch64-nat.c > index ee8c5a1e21d..928bb70d644 100644 > --- a/gdb/aarch64-nat.c > +++ b/gdb/aarch64-nat.c > @@ -22,6 +22,7 @@ > #include "inferior.h" > #include "cli/cli-cmds.h" > #include "aarch64-nat.h" > +#include "arch/aarch64-insn.h" > > #include > > @@ -225,27 +226,275 @@ aarch64_remove_watchpoint (CORE_ADDR addr, int len, enum target_hw_bp_type type, > return ret; > } > > -/* See aarch64-nat.h. */ > +/* Macros to distinguish between various types of load/store instructions. */ > + > +/* Regular and Advanced SIMD load/store instructions. */ > +#define GENERAL_LOAD_STORE_P(insn) (bit (insn, 25) == 0 && bit (insn, 27) == 1) > + > +/* SVE load/store instruction. */ > +#define SVE_LOAD_STORE_P(insn) (bits (insn, 25, 28) == 0x2 \ > + && (bits (insn, 29, 31) == 0x4 \ > + || bits (insn, 29, 31) == 0x5 \ > + || bits (insn, 29, 31) == 0x6 \ > + || (bits (insn, 29, 31) == 0x7 \ > + && ((bit (insn, 15) == 0x0 \ > + && (bit (insn, 13) == 0x0 \ > + || bit (insn, 13) == 0x1)) \ > + || (bit (insn, 15) == 0x1 \ > + && bit (insn, 13) == 0x0) \ > + || bits (insn, 13, 15) == 0x6 \ > + || bits (insn, 13, 15) == 0x7)))) > + > +/* Any load/store instruction (regular, Advanced SIMD or SVE). */ > +#define LOAD_STORE_P(insn) (GENERAL_LOAD_STORE_P (insn) \ > + || SVE_LOAD_STORE_P (insn)) > + > +/* Load/Store pair (regular or vector). */ > +#define LOAD_STORE_PAIR_P(insn) (bit (insn, 28) == 0 && bit (insn, 29) == 1) > + > +#define COMPARE_SWAP_PAIR_P(insn) (bits (insn, 30, 31) == 0 \ > + && bits (insn, 28, 29) == 0 \ > + && bit (insn, 26) == 0 \ > + && bits (insn, 23, 24) == 0 \ > + && bit (insn, 11) == 1) > +#define LOAD_STORE_EXCLUSIVE_PAIR_P(insn) (bit (insn, 31) == 1 \ > + && bits (insn, 28, 29) == 0 \ > + && bit (insn, 26) == 0 \ > + && bits (insn, 23, 24) == 0 \ > + && bit (insn, 11) == 1) > + > +#define LOAD_STORE_LITERAL_P(insn) (bit (insn, 28) == 1 \ > + && bit (insn, 29) == 0 \ > + && bit (insn, 24) == 0) > + > +/* Vector Load/Store multiple structures. */ > +#define LOAD_STORE_MS(insn) (bits (insn, 28, 29) == 0x0 \ > + && bit (insn, 31) == 0x0 \ > + && bit (insn, 26) == 0x1 \ > + && ((bits (insn, 23, 24) == 0x0 \ > + && bits (insn, 16, 21) == 0x0) \ > + || (bits (insn, 23, 24) == 0x1 \ > + && bit (insn, 21) == 0x0))) > + > +/* Vector Load/Store single structure. */ > +#define LOAD_STORE_SS(insn) (bits (insn, 28, 29) == 0x0 \ > + && bit (insn, 31) == 0x0 \ > + && bit (insn, 26) == 0x1 \ > + && ((bits (insn, 23, 24) == 0x2 \ > + && bits (insn, 16, 20) == 0x0) \ > + || (bits (insn, 23, 24) == 0x3))) > + > +/* Assuming INSN is a load/store instruction, return the size of the > + memory access. The patterns are documented in the ARM Architecture > + Reference Manual - Index by encoding. */ > + > +static unsigned int > +get_load_store_access_size (CORE_ADDR insn) > +{ > + if (SVE_LOAD_STORE_P (insn)) > + { > + /* SVE load/store instructions. */ > + > + /* This is not always correct for SVE instructions, but it is a reasonable > + default for now. Calculating the exact memory access size for SVE > + load/store instructions requires parsing instructions and evaluating > + the vector length. */ > + return 16; > + } > + > + /* Non-SVE instructions. */ > + > + bool vector = (bit (insn, 26) == 1); > + bool ldst_pair = LOAD_STORE_PAIR_P (insn); > + > + /* Is this an Advanced SIMD load/store instruction? */ > + if (vector) > + { > + unsigned int size = bits (insn, 30, 31); > + > + if (LOAD_STORE_LITERAL_P (insn)) > + { > + /* Advanced SIMD load/store literal */ > + /* Sizes 4, 8 and 16 bytes. */ > + return 4 << size; > + } > + else if (LOAD_STORE_MS (insn)) > + { > + size = 8 << bit (insn, 30); > + > + unsigned char opcode = bits (insn, 12, 15); > + > + if (opcode == 0x0 || opcode == 0x2) > + size *= 4; > + else if (opcode == 0x4 || opcode == 0x6) > + size *= 3; > + else if (opcode == 0x8 || opcode == 0xa) > + size *= 2; > + > + return size; > + } > + else if (LOAD_STORE_SS (insn)) > + { > + size = 8 << bit (insn, 30); > + return size; > + } > + /* Advanced SIMD load/store instructions. */ > + else if (ldst_pair) > + { > + /* Advanced SIMD load/store pair. */ > + /* Sizes 8, 16 and 32 bytes. */ > + return (8 << size); > + } > + else > + { > + /* Regular Advanced SIMD load/store instructions. */ > + size = size | (bit (insn, 23) << 2); > + return 1 << size; > + } > + } > + > + /* This must be a regular GPR load/store instruction. */ > + > + unsigned int size = bits (insn, 30, 31); > + bool cs_pair = COMPARE_SWAP_PAIR_P (insn); > + bool ldstx_pair = LOAD_STORE_EXCLUSIVE_PAIR_P (insn); > + > + if (ldst_pair) > + { > + /* Load/Store pair. */ > + if (size == 0x1) > + { > + if (bit (insn, 22) == 0) > + /* STGP - 16 bytes. */ > + return 16; > + else > + /* LDPSW - 8 bytes. */ > + return 8; > + } > + /* Other Load/Store pair. */ > + return (size == 0)? 8 : 16; > + } > + else if (cs_pair || ldstx_pair) > + { > + /* Compare Swap Pair or Load Store Exclusive Pair. */ > + /* Sizes 8 and 16 bytes. */ > + size = bit (insn, 30); > + return (8 << size); > + } > + else if (LOAD_STORE_LITERAL_P (insn)) > + { > + /* Load/Store literal. */ > + /* Sizes between 4 and 8 bytes. */ > + if (size == 0x2) > + return 4; > + > + return 4 << size; > + } > + else > + { > + /* General load/store instructions, with memory access sizes between > + 1 and 8 bytes. */ > + return (1 << size); > + } > +} > + > +/* Return true if the regions [mem_addr, mem_addr + mem_len) and > + [watch_addr, watch_addr + watch_len) overlap. False otherwise. */ > + > +static bool > +hw_watch_regions_overlap (CORE_ADDR mem_addr, size_t mem_len, > + CORE_ADDR watch_addr, size_t watch_len) > +{ > + /* Quick check for non-overlapping case. */ > + if (watch_addr >= (mem_addr + mem_len) > + || mem_addr >= (watch_addr + watch_len)) > + return false; > + > + CORE_ADDR start = std::max (mem_addr, watch_addr); > + CORE_ADDR end = std::min (mem_addr + mem_len, watch_addr + watch_len); > + > + return ((end - start) > 0); > +} > + > +/* Check if a hardware watchpoint has triggered. If a trigger is detected, > + return true and update ADDR_P with the stopped data address. > + Otherwise return false. > + > + STATE is the debug register's state, INSN is the instruction the inferior > + stopped at and ADDR_TRAP is the reported stopped data address. */ > > bool > aarch64_stopped_data_address (const struct aarch64_debug_reg_state *state, > - CORE_ADDR addr_trap, CORE_ADDR *addr_p) > + CORE_ADDR insn, CORE_ADDR addr_trap, > + CORE_ADDR *addr_p) > { > - int i; > + /* There are 6 variations of watchpoint range and memory access > + range positioning: > + > + - W is the byte in the watchpoint range only. > + > + - B is the byte in the memory access range ony. > + > + - O is the byte in the overlapping region of the watchpoint range and > + the memory access range. > + > + 1 - Non-overlapping, no triggers. > + > + [WWWWWWWW]...[BBBBBBBB] > + > + 2 - Non-overlapping, no triggers. > + > + [BBBBBBBB]...[WWWWWWWW] > + > + 3 - Overlapping partially, triggers. > + > + [BBBBOOOOWWWW] > + > + 4 - Overlapping partially, triggers. > + > + [WWWWOOOOBBBB] > + > + 5 - Memory access contained in watchpoint range, triggers. > + > + [WWWWOOOOOOOOWWWW] > + > + 6 - Memory access containing watchpoint range, triggers. > + > + [BBBBOOOOOOOOBBBB] > + */ > + > + /* If there are no load/store instructions at PC, this must be a hardware > + breakpoint hit. Return early. > + > + If a hardware breakpoint is placed at a PC containing a load/store > + instruction, we will go through the memory access size check anyway, but > + will eventually figure out there are no watchpoints matching such an > + address. > + > + There is one corner case though, which is having a hardware breakpoint and > + a hardware watchpoint at PC, when PC contains a load/store > + instruction. That is an ambiguous case that is hard to differentiate. > + > + There's not much we can do about that unless the kernel sends us enough > + information to tell them apart. */ > + if (!LOAD_STORE_P (insn)) > + return false; > + > + /* Get the memory access size for the instruction at PC. */ > + unsigned int memory_access_size = get_load_store_access_size (insn); > > - for (i = aarch64_num_wp_regs - 1; i >= 0; --i) > + for (int 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], 8); > 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) > + if ((state->dr_ref_count_wp[i] > + && DR_CONTROL_ENABLED (state->dr_ctrl_wp[i])) > + && hw_watch_regions_overlap (addr_trap, memory_access_size, > + addr_watch, len)) > { > /* ADDR_TRAP reports the first address of the memory range > accessed by the CPU, regardless of what was the memory > @@ -270,6 +519,7 @@ aarch64_stopped_data_address (const struct aarch64_debug_reg_state *state, > } > } > > + /* No hardware watchpoint hits detected. */ > return false; > } > > diff --git a/gdb/aarch64-nat.h b/gdb/aarch64-nat.h > index fee6bda2577..bc0e6297f40 100644 > --- a/gdb/aarch64-nat.h > +++ b/gdb/aarch64-nat.h > @@ -51,7 +51,8 @@ void aarch64_remove_debug_reg_state (pid_t pid); > *ADDR_P. */ > > bool aarch64_stopped_data_address (const struct aarch64_debug_reg_state *state, > - CORE_ADDR addr_trap, CORE_ADDR *addr_p); > + CORE_ADDR insn, CORE_ADDR addr_trap, > + CORE_ADDR *addr_p); > > /* Helper functions used by aarch64_nat_target below. See their > definitions. */ > > base-commit: e78337d5780c9d837e186c22c11eb8f9ed5bac62