From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id QcjBHxPFo2Z5sDIAWB0awg (envelope-from ) for ; Fri, 26 Jul 2024 11:47:31 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=bAEQtVF5; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=bAEQtVF5; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 6AA701E0D0; Fri, 26 Jul 2024 11:47:31 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 00D6E1E097 for ; Fri, 26 Jul 2024 11:47:29 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AADFB3858D28 for ; Fri, 26 Jul 2024 15:47:28 +0000 (GMT) Received: from EUR02-DB5-obe.outbound.protection.outlook.com (mail-db5eur02on2056.outbound.protection.outlook.com [40.107.249.56]) by sourceware.org (Postfix) with ESMTPS id 4B1123858D26 for ; Fri, 26 Jul 2024 15:47:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4B1123858D26 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 4B1123858D26 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.249.56 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1722008827; cv=pass; b=VXXixxMU2Am+oTJXYdvbHZHV7OTYUoBkPgJ0vRb2NimMtU97cD90ItkiUPiitRlj0vNQkas7LwePQKEmqVPusAQt6dcmmgtGrOuZtyFUzajmAu8ysNHGaaa2IEVphbigp6HKEKdg3j8L2Z//PEa417NTfVtg6gnv3BVjeBPL/Gc= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1722008827; c=relaxed/simple; bh=kYcvAn3awbSwlloZr8IIWWVTuqnDNrad3UONGSo+ZzE=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=Y0cTyjgju8Cvg/sa1qRzgG0QSKNREQS9d+0ybeP5bNizUMwITX0asDemk73d57ifsMtSsOqTo6/uzQUKzczMLxLDoKtm97pwVV//s45fRJ0RG+0Bg8m7bAnmBENxq2zuF57KlDZWrF0RCYQJmNBmeJIi/exbx4Dnpa3UngKGQb4= ARC-Authentication-Results: i=3; server2.sourceware.org ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=cfs/BnM6WwWWyBR1xB7wx4ZJoZLRSz7F0bSRqLF5mVnKD00tbZjw2wdAPQ9gVAFyjPZn/6lZLt2DEj5I+eBItuU5v3oH6MuRY6Seglb/DY7kILejdmkV5BljIBwtzSDnTcTv3YEsxzWILj5H/JqJ5qti3uGn9EdKbkNGxy65RtvZL9suu8bRIasWHd+hM3fb+6eoCCs9/6+w2i/yA/T29FYFlZ2OCddgG3UUfdJ4HhdDlpXr/qCQerVxSProsqVobSiAVaE8/UlTbAfwWEx4i7zmolmMfi7LWp54u8xrsOUaROTVzqwP3u9qYdCDclNrbL/OcMSZ4B2ZP1dLOwstCw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=L5niIExQZgwZvnHOgzKDRQQAvHJybie73+xQNO0TLkI=; b=n2b301r4BZujT1IS8ZaPIJK4p5KpaZZPJz1e8TMQgefGh29qE8TJYTD9om2To3DKyacgVPz1wBcXMwaeWkGpVkOd+Sj0Rhtnl8R1yjiOvnp4+4af4CiUJ11lEW5j0IP40G90moVopgbTYi7CXTUqKbPv0ONCZpoqHL3mvUpwR8rMq5gRiWWJg1x6hq1HXZToUIBEEIExeUJ54cCwZsf2JBG5ngXaX5RVBzpNf405TWis+L+eaLydGuda6zdnv0fmBlKdJs9SMRi2K8nmxPdOEsDsaefhjfFDbe3fyAJBWrvYZmceTieWZPPhGNicJNuGEioOQcQr4WQn/PwMHwV/UA== 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=arm.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=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L5niIExQZgwZvnHOgzKDRQQAvHJybie73+xQNO0TLkI=; b=bAEQtVF58+1t3C81a4gB0jEgG8EZX4a/mtEp6+Nnf6KpNQTOS6gyKebQmZhOkgv06ZaQkrbszhXH5jL04+S6aTNHwsgrkhB5bKmIZE9umf+GRSBU25DHU0vmYah703wDjT/wVqSGiuPu6u2BuZM0Ga3O0UUfGBwJGPHDmmbsps4= Received: from AM0P190CA0011.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::21) by DB9PR08MB7493.eurprd08.prod.outlook.com (2603:10a6:10:36e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.16; Fri, 26 Jul 2024 15:47:01 +0000 Received: from AM4PEPF00027A5F.eurprd04.prod.outlook.com (2603:10a6:208:190:cafe::42) by AM0P190CA0011.outlook.office365.com (2603:10a6:208:190::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.28 via Frontend Transport; Fri, 26 Jul 2024 15:47:01 +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=arm.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 AM4PEPF00027A5F.mail.protection.outlook.com (10.167.16.74) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7784.11 via Frontend Transport; Fri, 26 Jul 2024 15:47:01 +0000 Received: ("Tessian outbound 93748f77c01b:v365"); Fri, 26 Jul 2024 15:47:00 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 1514efe9585a0852 X-CR-MTA-TID: 64aa7808 Received: from L6b1d9fee480f.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 726E354A-5EF6-4C87-B207-8116DA956886.1; Fri, 26 Jul 2024 15:46:54 +0000 Received: from EUR03-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id L6b1d9fee480f.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 26 Jul 2024 15:46:54 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ov4vkZIn1KXMjdlE0x1bdp6UtUB3bBffdbejWhuR9dqH5vwjAVR6C3cVh4hc78TB6vl8LyOJIPNrTJEQX/s4Jfbnfagyi6FRjoMPEgpdsvSRlnWKmNhgX7ZfhbeQ+Gd6w8lCMHekNsDhZiDrLhYAjWzgPtXMC6BnOE/im/UlJemSVWvPWpimVGajqIgucetNYOmRkHgxih9CrgUj3+faWizyrqCEazkL44ZyqTwz9kA9DERx7aLsQLfiakJw+is5Sx8DUiUIryx+dp69qsgk1UyAV0NjfvKXClQLX0XJByZLY4Gynui/MxgPQasjGWAfnya8AhzIePscpCJPdXPiiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=L5niIExQZgwZvnHOgzKDRQQAvHJybie73+xQNO0TLkI=; b=ZvDFp6kpzmBlokUOiVQCg3UAxtDiMaa3VIFpdqlZqEuK+O//73mHj7RkdwRXp5o9AnOBKt7yuSiIEMLr1J6o8R7fbZtuDWjaMXaLEYvBj2M+mvat+3EZuwMIsZFELCxe5DppkyoLIWDg3MUiI0tkX+N6qrcLP8mkEBUmUctig3AizNr36SiFcChFyHCSJ5LnQdcBb5xE9hMhdN12lWMXucWUAq62nIjDeXqcPXH1gtTvBMF+sh9GKF+mCxNOCMY0BBMjw55YGKO7YlZfT8ay1kdl5Pk2DT4ILnhiGDwDLaZnSgJRqBGRnZySBRPdZ291IqRbflL0gh53FO0dTjawlQ== 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=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L5niIExQZgwZvnHOgzKDRQQAvHJybie73+xQNO0TLkI=; b=bAEQtVF58+1t3C81a4gB0jEgG8EZX4a/mtEp6+Nnf6KpNQTOS6gyKebQmZhOkgv06ZaQkrbszhXH5jL04+S6aTNHwsgrkhB5bKmIZE9umf+GRSBU25DHU0vmYah703wDjT/wVqSGiuPu6u2BuZM0Ga3O0UUfGBwJGPHDmmbsps4= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from AM8PR08MB5842.eurprd08.prod.outlook.com (2603:10a6:20b:1d7::17) by AS1PR08MB7476.eurprd08.prod.outlook.com (2603:10a6:20b:4dc::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.18; Fri, 26 Jul 2024 15:46:51 +0000 Received: from AM8PR08MB5842.eurprd08.prod.outlook.com ([fe80::c971:a08b:403b:35fd]) by AM8PR08MB5842.eurprd08.prod.outlook.com ([fe80::c971:a08b:403b:35fd%2]) with mapi id 15.20.7784.020; Fri, 26 Jul 2024 15:46:50 +0000 Message-ID: <8d4c3fa2-292b-499f-9f79-05407df4d7e5@arm.com> Date: Fri, 26 Jul 2024 16:46:48 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] [gdb/testsuite] Add xfail in gdb.base/hbreak.exp Content-Language: en-US To: Tom de Vries , gdb-patches@sourceware.org References: <20240717151055.21480-1-tdevries@suse.de> <6ad9fbd8-1977-4688-9534-00d1271bba99@arm.com> <6d4a4345-0247-4c1f-9db3-e0347b475e4b@suse.de> <4e82e0bc-3e3a-4461-be2d-7b8d4785e1a5@arm.com> <0f4d0d87-458f-482d-af49-fc6a65b15daa@suse.de> <678c782d-a7c6-43d7-a454-2d6f21967c78@arm.com> <01b531eb-5090-43c8-a9a0-11fc090e0291@arm.com> <8474a617-87f2-4c73-94fb-b0e91c9c62fb@arm.com> <7a3e65ee-af3a-4134-8719-cbace79afd92@suse.de> From: Luis Machado In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0129.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:193::8) To AM8PR08MB5842.eurprd08.prod.outlook.com (2603:10a6:20b:1d7::17) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: AM8PR08MB5842:EE_|AS1PR08MB7476:EE_|AM4PEPF00027A5F:EE_|DB9PR08MB7493:EE_ X-MS-Office365-Filtering-Correlation-Id: 87a7a06b-4157-4de7-7019-08dcad8a308f x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|1800799024|366016|376014; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?MktRNCtZeGpIS2pkNCtJR0IzQVczUUZDckxYSStCOXdLSGRvNnVvdGEzb2ty?= =?utf-8?B?SEVzb3BPTDVGcXJBM1dicXc3Y2dMaEZqL2JpNEMyMSszZVZETDRjbElsWHBF?= =?utf-8?B?bnoraHJZVGRPYWpyaWtuRENRUkJCVWdoM2g2ZDY4L3NlSTRhUGRyOTdxdGY0?= =?utf-8?B?RHUyV094VjJhOVZueFoxMHRyTk5wYmJmc2VpU2JuSm9hZHd6M3R6S0J2Rk5y?= =?utf-8?B?QzM0UmRodG9Nck1Kbm5VTjB6NkpQWmxvOTd3Tm5uR1hYVVlSd2QrM3ZUeThm?= =?utf-8?B?M3Q3N2MzM0xaRk9HVTZabVNJVGFGUUJaSG9od01mUjRtVitMdzRXcmUvOVJt?= =?utf-8?B?OWlBYVVveTRZWkNvVTJlbDd3RktVN0w3V1RxRzhHR3VPdFdZMDZLR1N5ZG1h?= =?utf-8?B?VWdzN2xFeXpnMVcyampHVElBeEI5bEV3OUtHRUh6aVFqWGJhRnZSQVdhSVZa?= =?utf-8?B?TFJoM0k0VktaSzcwcEZYNHhVcDJ3eGFseW94dnVjMG1MWCtFYjRnT2NVMlpp?= =?utf-8?B?RE0xczNPT2h1OGpnWXppekdvMzM0dDZTbHh5bEFnNWhNNFFnMU1Yb2VGbzhQ?= =?utf-8?B?RXFjQmNWSzFaa1lEOFpwbTZoWTMrTFJ2aDk1cUxhZ0F6MGlYQ25ZVHNKM0Fv?= =?utf-8?B?RmRLdW1YdXFxbFlla1dCbHZ0S0VKd1EzQzVWY25ubU9TMlVkL3NJZVgxY2RM?= =?utf-8?B?WTAzV2VweGxVZmtoTjVIMDZXM0hMdFhoU0JLS3pLUEM0cFlsbmgreStjdHFl?= =?utf-8?B?cU02REdUNE5WV1l6NkVKOCt0TkdDQldHcUtXV3JNMEJZMWdaUFBwN2ViQ0tJ?= =?utf-8?B?Y1pJR2EzeWtaN2JuYS9vakVUMVNtS3ZwQVhmWFhGTzROcEI5WXFWNjVSb1Iw?= =?utf-8?B?dE9EbGI1RmE1a2VCYkNyNnUxbVY1U3Rod3RMRXMwVXNsRHZXd0g3MDQ2VDRV?= =?utf-8?B?K0I2M2Z6L2x0ZkFxVmtaMWExOGJaZXZRRjlNeGRsVFJsc2xpOUE2WEtzNTBj?= =?utf-8?B?NHdIZzdHWU9KTTMwUUNubFc2MnFzKzMrZ3BhZ0xoQXNpRG5yUWNSWUx2eFo3?= =?utf-8?B?a1ZRZnJJZmR5MTlPTHZNMmVBcmVRbzV3VkljT3NJZkJydWR4VEtJL25OVlNI?= =?utf-8?B?QndwYnppLzZ6WXl1VElaQ3N1KzEyZDB6ZzNlTXI5Z3NJR3pBSWtBdCtFMk14?= =?utf-8?B?UisvekZFdlFXMWFBdWZEVy9kVHJvVDV2OUlsUmtvY29abzRnZVRsN2s0c3Ju?= =?utf-8?B?VlluWWRnRlY1VDloZWd2M0VTK20xb0UrQ3Rad1d6eWJPVVQ0emlaRVZsRnRX?= =?utf-8?B?OXA3MXE3SlZ6VXdUU1drOTlHbGN4dUFoTzZRN0tEVE0vNWhPOHQ3ODl0NXpH?= =?utf-8?B?TXlSN2I2d2tRdUQ5dDNiaXRRMlFVZEhORU80YXFRcUo3aTgzbWtGaEFCTHVq?= =?utf-8?B?WHc4WUVyNjVZSUl2MzN3NGxlWnJmRlRSSnFUdGZUWjM4a2JoZ3djNUxsd0RD?= =?utf-8?B?TXFvRkhROFJzeW95REtUalByejdWNXBzU1VrVmhKVlI4K3cycS9VWHBydWpS?= =?utf-8?B?Q21mTU40blVMa2lNSFhoTUY3dXBaMVNXb0Q4eTJ3bUU3UDdZTmlpM2JSTTlz?= =?utf-8?B?Um8rZVZOY0FoU01OMVdoS002djZYZ0NZcUtWci9VTlBObitGRWhpS3QrUEZY?= =?utf-8?B?VEUycGZTWjd6Mll5N2dweTY5NThzQUF4MThhaHdWT1dCYXQwQi9taTBaUkI5?= =?utf-8?Q?4CkLi9Q4TMXGDcT0i0=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR08MB5842.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(366016)(376014); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS1PR08MB7476 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-SkipListedInternetSender: ip=[2603:10a6:20b:1d7::17]; domain=AM8PR08MB5842.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM4PEPF00027A5F.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: cde08000-acfb-45f2-a169-08dcad8a2a46 X-Microsoft-Antispam: BCL:0; ARA:13230040|35042699022|1800799024|376014|36860700013|82310400026|34020700016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?cXdvbTNMN2tuVytJdUdCTCt6MzNMTEdnTEZkUXUyOTFhWm95Uk9GVEorZ1Ni?= =?utf-8?B?azcvN0U2NC9uc1pwQ3IrU2JsdjQvakR4ekxkNnl4TDlhd1VQM0RCUXFObE45?= =?utf-8?B?b0JXRWVRYi9rTHhGNFNIeHZUQmVwUlRGN29uT1hTKzR5SWRaOGh6cUVKT1ZF?= =?utf-8?B?VDNUOUdVSVdRbWhiVkQrVG1sa0FRbDJzMDhTOEtlYUREbEtScjZ0cEpWZzRm?= =?utf-8?B?S1orVGQzSHdzeW9reUN5L2plWW9xWnIyV2RYeEFwdW1wZG1yYkI4Z1JpcWlQ?= =?utf-8?B?dGd1U3NYdzA2UitMN0RXdVpTME5BSWEvTXRXVFArNHczaFdhVGs5OFZPN0hR?= =?utf-8?B?UkloczE1Sm5zTzhFRUxYQWNzTGpiajBaZmFVb2sydTBiU1ViTWo1YittNDlt?= =?utf-8?B?MVdFcWpNOVlMU2ZscWQ0bVFLWmlRcWt4UTJ5SEJ2YTlRZ3RPUXVuQkttYUJy?= =?utf-8?B?QkNnTC92cmY0YXNIenhwcXdSOFJCU25lU2RMSExYUmxYeGZadi83aWw1UWd1?= =?utf-8?B?d2lralM1TDZOcUVRTzBDM252V0ZlL0luYmJ5ek5vcEhGREM2WEpqZFVEOXBo?= =?utf-8?B?YnpzVmJqVjg5SG5EejBoY3ZiNTZPVE1NT0R3WktNY0NnZThtTFVBMUp1ek55?= =?utf-8?B?ZE4xWWVnQUUySWRwYjF5cjFHNGR6K0R4bEppalV3SE9vWXJkNXIrS1pVOVlB?= =?utf-8?B?OHI1OG1GSFYxUlg4ZU43SG1GZjhtQ2R5RjdmYitzQlRlNTBOemxkbDErSXB3?= =?utf-8?B?eTJVd0tpWk9ZQUROalFtWHIyV3RQRXlvd0o2Q0ppZDN3YmNzM09yR2JnajFq?= =?utf-8?B?L1piNjkydW14SCtCSjFjMW1tL0lpVVh1RVRKMHBlSHRVTjNteVpsNzIvUnZF?= =?utf-8?B?dW9Hblpxa1BVcW1oVFgzeWtXQnB2NWhBeC9FZUdHajZleng3KzJadjJoL0JO?= =?utf-8?B?RkFGZ05Qc1dSd2dwYVRpbXBNM0FaaGp4SjNISUJHVlpESmJOaHRrbCs3ekxw?= =?utf-8?B?cnVrakVxK2tKMkZBcmFxK05MUkV1L2VQZUdGYi81a3llcm0vM2VEa3hNMzJt?= =?utf-8?B?Y1ZQSzF2Mmo1OU1rQmxydURYV3M2M1RMZFhOemk2c2RxYyswMWtLMWlINDVT?= =?utf-8?B?ZUYvTUFyN3FSSHZVdHE2QSswYlFtelpDSzlOR25ZR3BLdTRqeDBIeERYaTR6?= =?utf-8?B?bUEwdzlsdGVlUjljZzIrNXdZUmlhd0tiS2Y2SXJsNURyVHpveFRYaHpnUG4v?= =?utf-8?B?SzdtaTAveWVTL1QrMjJsN1g0SjdjOVpwOTV5bGZTQzZGWFgzNkt5QU1DM1V6?= =?utf-8?B?bktoNjF0Vm1JdnM5T3JmcERRZEpmcVdCWnZYOFE4TXZUYURjYXRXNXpzRDJG?= =?utf-8?B?NXVZRU9lT1EzRkdPNEFRNGZOTlFKd1M5MXV0VVk5OUxiRzhNc095VXROajkz?= =?utf-8?B?S1BrRDFvTmI1QURQQ0poazA0dWlWNG1UR3E1YVBGWkE5Rkp2OVFwd1ptU2NK?= =?utf-8?B?czRXSXpFVEFIaFBTSW1oT1drS2p6enNGSVBLVGxzTWwvaGxNY0dPZ3ZQWGdP?= =?utf-8?B?VEZQSkhUcXpUa1l2K2xiQWdhRXM3bzM0aFRsM1RrSE1wQnR4QXlwcVFUc1No?= =?utf-8?B?M3lRU01mR3Q5eXplOFc1TTM4bHl6bEgybmd0VDB1aUxnbVdUQ2c3Si8rU2xp?= =?utf-8?B?aCs0eTNNTE5HRUtHTk0wOXlTRDZWLy9GMkFTRkVrTThBK1pDTVpIdTZKQlpz?= =?utf-8?B?bFNvdXMxRTFIck5HclYxSXVQR21qSnVnN2VFK0l0TGpjREZvb0hpTzhuK0ZJ?= =?utf-8?B?dlRpbFdFVGNvcjJzZENobTZqSlQ3Q2drSjdKTkQwbGd2NEJ3WWVVa0ovYm0w?= =?utf-8?Q?9BwtzKsyRebrn?= 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:(13230040)(35042699022)(1800799024)(376014)(36860700013)(82310400026)(34020700016); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jul 2024 15:47:01.0785 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 87a7a06b-4157-4de7-7019-08dcad8a308f 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: AM4PEPF00027A5F.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB7493 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FORGED_SPF_HELO, 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 7/26/24 11:01, Tom de Vries wrote: > On 7/26/24 08:30, Luis Machado wrote: >> On 7/26/24 07:28, Tom de Vries wrote: >>> On 7/25/24 17:22, Luis Machado wrote: >>>> On 7/25/24 14:52, Tom de Vries wrote: >>>>> On 7/25/24 00:59, Luis Machado wrote: >>>>>> On 7/24/24 12:56, Tom de Vries wrote: >>>>>>> On 7/24/24 12:45, Luis Machado wrote: >>>>>>>> On 7/24/24 10:28, Tom de Vries wrote: >>>>>>>>> On 7/24/24 08:53, Luis Machado wrote: >>>>>>>>>> On 7/24/24 06:25, Tom de Vries wrote: >>>>>>>>>>> On 7/23/24 12:02, Luis Machado wrote: >>>>>>>>>>>> On 7/17/24 16:14, Luis Machado wrote: >>>>>>>>>>>>> On 7/17/24 16:10, Tom de Vries wrote: >>>>>>>>>>>>>> On an aarch64-linux system with 32-bit userland running in a chroot, and using >>>>>>>>>>>>>> target board unix/mthumb I get: >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> (gdb) hbreak hbreak.c:27^M >>>>>>>>>>>>>> Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M >>>>>>>>>>>>> >>>>>>>>>>>>> That is a bit odd, but it goes through the compat layer, which is not exercised >>>>>>>>>>>>> as often as the 32-bit code. >>>>>>>>>>>>> >>>>>>>>>>>>> Let me see if I can reproduce this one on my end. >>>>>>>>>>>> >>>>>>>>>>>> I managed to reproduce this. I checked with the kernel folks and this should >>>>>>>>>>>> work, but I'm not sure where the error is coming from. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Luis, >>>>>>>>>>> >>>>>>>>>>> thanks for looking into this, and the approval, committed. >>>>>>>>>>> >>>>>>>>>>> Are you or the kernel folks following up on this, in terms of a linux kernel PR or some such?  It would be nice to add some sort of reference to the xfail. >>>>>>>>>> >>>>>>>>>> It's in my TODO. I'm still investigating to understand where the error is coming from. Once located, I plan to check with them for their thoughts and a possible >>>>>>>>>> fix. I don't think the kernel folks use the PR process much. We could probably ammend this commit later on once we have more information though. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Ok, I spent some more time debugging this issue this morning. >>>>>>>>> >>>>>>>>> After reading kernel sources for a while, I tried out reversing the order in which the Breakpoint Register Pair is written in arm_linux_nat_target::low_prepare_to_resume, and ... the test-case passes. >>>>>>>>> >>>>>>>> >>>>>>>> But what would change with reversing writing to the control registers, from gdb's perspective? >>>>>>>> >>>>>>> >>>>>>> Well, from gdb's perspective, the only difference is that both ptrace calls succeed, while with the original order the first one fails (and consequently there's no second call).> >>>>>> >>>>>> I've investigated this further, and I think I see the reason why reversing works. It seems handling of hardware breakpoints is slightly different between aarch64 compat and >>>>>> 32-bit arm. >>>>>> >>>>>> In summary, it seems aarch64 compat attempts to set the address before doing anything with the passed control register value, in arch/arm64/kernel/ptrace.c:hw_break_set. >>>>>> >>>>>> We can see it punts if ptrace_hbp_set_addr returns an error, which is where we're failing with EINVAL. >>>>>> >>>>>> For 32-bit arm, in arch/arm/kernel/ptrace.c:ptrace_sethbpregs, we do things in a different way. The important bit is that we only call modify_user_hw_breakpoint after >>>>>> we're done setting both the address and the control register. >>>>>> >>>>> >>>>> I'm looking at that code, and it seems obvious to me that modify_user_hw_breakpoint is called both after setting the address register and after setting the control register.  Could you double-check your observation? >>>>> >>>> >>>> You're right. It gets called twice, one for setting the address and the other for setting the control register. I missed that when reading through it. >>>> >>>> So it may still be the case this is also an issue with the 32-bit arm code. I'll have to boot a 32-bit kernel to check. >>>> >>>>>> For aarch64 compat we call modify_user_hw_breakpoint for both ptrace_hbp_set_addr and ptrace_hbp_set_ctrl. >>>>>> >>>>>> When we have a new task and attempt to use a hw break, the kernel initializes the hw break slots. It does so in arch/arm64/kernel/ptrace.c:ptrace_hbp_get_initialised_bp. >>>>>> >>>>>> Once a slot is initialized, it isn't initialized again it seems. We will only reuse the slot (with whatever information it has, since we will replace it anyway). >>>>>> >>>>>> With the above context, it seems we're running into trouble when we have an unaligned thumb address (offset == 2) and the slot's bp_len is set to ARM_BREAKPOINT_LEN_4, >>>>>> which is the default (or it is there because we previously set a 4-byte hw break on this slot). >>>>>> >>>>>> We can confirm that setting a 2-byte hw break works if we use an aligned thumb address (offset == 0), because we use a different switch case entry. It also works if we first manage to insert >>>>>> a 2-byte hw break on an aligned thumb address, delete it and then try to insert the hw break on the unaligned thumb address. >>>>> >>>>> Confirmed, that also works for me. >>>>> >>>>>> This is because inserting a hw break on an >>>>>> aligned thumb address sets the bp_len to ARM_BREAKPOINT_LEN_2, and we eventually reuse that slot during ptrace_hbp_set_addr, which, I think, is the bug we have in the kernel. >>>>>> >>>>>> We shouldn't be reusing that information. Instead we should use whatever the user passed as the control register value to the ptrace call. >>>>>> >>>>> >>>>> IIUC, your hypothesis is that the kernel bug is that the check for address vs breakpoint length should only happen when writing the control register? >>>> >>>> I think so, because we need to validate the address against the length of the breakpoint that is being requested. And that data is part of the control register. >>>> >>>> The problem seems to arise from the fact we need to do two ptrace calls to set things up, and we're trying to validate both calls. >>>> >>>>> >>>>>> For a potential workaround, I think we'll need to check for attempts at inserting a hw break at an unaligned thumb address (offset == 2). If so, then we do a dance of >>>>>> inserting the hw break at the aligned version of that address (offset == 0), only to make sure the slot's bp_len is correctly set to ARM_BREAKPOINT_LEN_2, and then >>>>>> proceed to insert the hw break on the original requested unaligned thumb address. >>>>>> >>>>>> Off the top of my head I can't think of potential issues with this approach. I don't think the kernel checks if we insert two hw break's at the same address, so that >>>>>> corner case might not be an issue. >>>>>> >>>>> >>>>> I've submitted a patch implementing that approach ( https://sourceware.org/pipermail/gdb-patches/2024-July/210681.html ), basically doing the following ptrace calls: >>>>> ... >>>>>            1. address_reg = bpts[i].address & ~0x7U >>>>>            2. control_reg = bpts[i].control >>>>>            3. address_reg = bpts[i].address >>>>> ... >>>>> >>>>> [ Note that a fix for the kernel bug formulated above would mean that the address vs breakpoint length check in step 3 would stop happening, and we'd need to write the control register again in a step 4, to get that check back... ] >>>> >>>> That makes sense, as we need two ptrace calls for this operation >>>> >>> >>> OK, I'll send a v2. >>> >>> I also think that it's probably a good idea to do the first control_reg write with the enabled bit switched off. >>> >>> That way we're not actually enabling a hw breakpoint on the wrong address. >> >> Makes sense to me. >> > > Well, it turns out that that doesn't work, so I've left that part as is. > > V2 submitted here ( https://sourceware.org/pipermail/gdb-patches/2024-July/210709.html ). > >> I'm in the process of booting a 32-bit kernel to check what is the situation on 32-bit arm. >> > > Great.  Unfortunately I don't have a setup where I can try that. Ok. I've confirmed the problem also exists for 32-bit arm, so I also see the ptrace error there.