From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id eMP9A32HoWY13DAAWB0awg (envelope-from ) for ; Wed, 24 Jul 2024 19:00:13 -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=OlEfAeAQ; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=OlEfAeAQ; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id DD7741E0D0; Wed, 24 Jul 2024 19:00:12 -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 642661E097 for ; Wed, 24 Jul 2024 19:00:10 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CF818385DDC1 for ; Wed, 24 Jul 2024 23:00:09 +0000 (GMT) Received: from EUR03-VI1-obe.outbound.protection.outlook.com (mail-vi1eur03on2043.outbound.protection.outlook.com [40.107.103.43]) by sourceware.org (Postfix) with ESMTPS id AEC0E385AC29 for ; Wed, 24 Jul 2024 22:59:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AEC0E385AC29 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 AEC0E385AC29 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.103.43 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1721861986; cv=pass; b=Ngrgm4tubuj8eE0QjkrbYcXZUO2MTc5446fVywM3W6Ngdpa9mmJKSzBMt0Son+WTs2i0vzu0s+ms8tStyZTT6qyPbviAN9WSK4wwe5oGYfk/f3+kX2CjX/I1cum9ux1nZJNkGSWL+KcYJsAFVSoJ/0LVMoO9/J3C2r6NvtVoAGY= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1721861986; c=relaxed/simple; bh=AF8M5PhM9MRH+igw840MoMTH2XbYmZWRJOto7d7sZDQ=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=GfIWwYHrs7nNVCvmeJEhlV3XhV3Xz0JWeoATjpG5KaXQPeyvIw8ooYNZrz0RVYZIfWlo1kwuYNWE+/m7ipeyVFEbaFXB1hJ4XenM9303W/MOF9Jk/VGxsIJttAoEqYndwQ9+Yrd2nRWf8lkxmowqYDEauNGcbyri8OUrseM/H+U= ARC-Authentication-Results: i=3; server2.sourceware.org ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=MOIzhkjNUsCny7OtQxcEbojuJBZjmoNcHfbzY+m4uv1dbb/cc4o9+Xl/xrb3YHQ3yuTDWBuARV0Vl/mLRqn2vNsv859zY2GXoNQ76iRHpGUBOn+dH/izc9F6uh9ByDCOnuirR+otOgEXluV2WkJB5MmcY/Gz5CD+Pg3vRQZjWKh8f81uGc8kiFwVK2aw9K6/UI5bmSz9tI2BgypzCkeIo8/4T8RoCHBZQVS2V8yahbaNjYoKfDOIEoDvD+E3KZTtLO8hyKVT1uBenUhv9CuASIPLjvrcvkgqhah2Q/XO0yrAD08B2NiwqXfSt6S0PMaCiRA8v3ohS6KHR4PYmhOLGw== 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=M0GVV+XCLeQ/kP0GP6Ahqzxw9mQPZ15mZ9HC4IteLAU=; b=LXs+HQNmoCjM5vbGsfVlvXrJyZw49GkaD9bfu15Xqce3NOgSE1vlQoVGYaG/GiloNvIkqSPqpYFkyMxl7qR4Y0iMUx9s/4ZMFycyDX6Gkqxeh7yf8aslB8FdNI/aSYYK3eGlrP4IVHnmL/mqhwyaQtSMjecZI2+4i3qiv/AAzz07P2Ub8xrdkQZtSlVhc+qQn0UsFV6d+6gsIZiL9t/jJ2VKhxu/krHX3jaOF2f6W/wlKKUT6C3zQQsKUS2wPxicB9i3iuVDpnHXTHn5TLo3lkn4BvB8Lm8xlLw2SOO1qAAfu6k9waUrQhU0nD2gbhB9v8hMQLR5Ob11ZrkUpKhi6w== 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=M0GVV+XCLeQ/kP0GP6Ahqzxw9mQPZ15mZ9HC4IteLAU=; b=OlEfAeAQq6sC28XDSnudVasps+2+RC8Tj2S3IoSe11Iyq7BfQVHHo1pBGhU3joTGJy8OBlGwwojRZIaQt8XYulLNJXOFLO6QmnbXN+jk/umWsY0VZbvBvsZ2uhdnrTJ0aiL7nYrnIrNtlmKDKjZy3q/zbEDVqiGJ/itK/dD0rHU= Received: from DB8PR06CA0055.eurprd06.prod.outlook.com (2603:10a6:10:120::29) by AM8PR08MB5617.eurprd08.prod.outlook.com (2603:10a6:20b:1dc::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.20; Wed, 24 Jul 2024 22:59:39 +0000 Received: from DU2PEPF0001E9C1.eurprd03.prod.outlook.com (2603:10a6:10:120:cafe::78) by DB8PR06CA0055.outlook.office365.com (2603:10a6:10:120::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.14 via Frontend Transport; Wed, 24 Jul 2024 22:59:39 +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 DU2PEPF0001E9C1.mail.protection.outlook.com (10.167.8.70) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7784.11 via Frontend Transport; Wed, 24 Jul 2024 22:59:38 +0000 Received: ("Tessian outbound 93748f77c01b:v365"); Wed, 24 Jul 2024 22:59:38 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 9f22bb050ab0771d X-CR-MTA-TID: 64aa7808 Received: from L993cfee52a65.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 91E0A6A3-650A-4C95-95E7-1FDCEF2F055B.1; Wed, 24 Jul 2024 22:59:32 +0000 Received: from EUR02-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id L993cfee52a65.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 24 Jul 2024 22:59:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IsyM112uL2SBmG8Fak1do/sBUadcPTPSy0yG0G6iKtOp0zBjdVYCCA2rK31edt4vCo+CaW9X0umNXm9lHBQrxbGLtDgH6PTk38wjX21X6VBd+BUdKtYvsFtqvBTqy8k5WFRP54uRHh7EEIrw6b0y6RuNrSecRgDEftUJ9f7HeKoCuvJueew70KtulpSFeZ0jZbfVg6G8iRxWCdT5V1Lb9fS43VTN+H12KiT03zn/r6YWVif38JQWKeCk9+axR82za+RrDh8z8aJWRdyqidqaUs9qpGHwKGYZVKid6NFJi6CLOdmTteTAYCxhLTIVpBRfl1OFgby23dXDRTugQq1iRw== 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=M0GVV+XCLeQ/kP0GP6Ahqzxw9mQPZ15mZ9HC4IteLAU=; b=uiDaMuOLzZmWXbgDOwU30HQkxD7DYie6AQR/em0k4xfn+AMHCFQ0zNIYfz/+fBo16W7J96OADIQeMCRKZ4GPYY93CXOXYOWRaGHjl6XriJ28rR7JCDKcPqK3ksy0R2uDnybJdb8QYl2bEDOlQGsSGqyGEdZh6x9iMUg+dEAaNqNUSK26pwMiIAJzxR/iwwDJ16VlS2zgFT5PhQUASTirll4BZqaI850qlBUwnobBFdI4TNMAE4XbuO4jENm5qsl4RJ+p7iY+dKGqsyWjcg2v/08hj4hsoYJDLznmk2Q0MDnXS7sViG8gTUcPutLAOgfeOgJM6ZpxXR6QCBMxY8joFQ== 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=M0GVV+XCLeQ/kP0GP6Ahqzxw9mQPZ15mZ9HC4IteLAU=; b=OlEfAeAQq6sC28XDSnudVasps+2+RC8Tj2S3IoSe11Iyq7BfQVHHo1pBGhU3joTGJy8OBlGwwojRZIaQt8XYulLNJXOFLO6QmnbXN+jk/umWsY0VZbvBvsZ2uhdnrTJ0aiL7nYrnIrNtlmKDKjZy3q/zbEDVqiGJ/itK/dD0rHU= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from PR3PR08MB5852.eurprd08.prod.outlook.com (2603:10a6:102:8e::21) by VI1PR08MB5517.eurprd08.prod.outlook.com (2603:10a6:803:139::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.16; Wed, 24 Jul 2024 22:59:26 +0000 Received: from PR3PR08MB5852.eurprd08.prod.outlook.com ([fe80::f44:d113:1c29:825d]) by PR3PR08MB5852.eurprd08.prod.outlook.com ([fe80::f44:d113:1c29:825d%3]) with mapi id 15.20.7784.017; Wed, 24 Jul 2024 22:59:25 +0000 Message-ID: <01b531eb-5090-43c8-a9a0-11fc090e0291@arm.com> Date: Wed, 24 Jul 2024 23:59:26 +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> From: Luis Machado In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0080.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:190::13) To PR3PR08MB5852.eurprd08.prod.outlook.com (2603:10a6:102:8e::21) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: PR3PR08MB5852:EE_|VI1PR08MB5517:EE_|DU2PEPF0001E9C1:EE_|AM8PR08MB5617:EE_ X-MS-Office365-Filtering-Correlation-Id: 1ce0d36f-256c-4749-e373-08dcac344b77 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|376014|366016; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?MkluVW9Cd3ZmRWhtVG0xRkY5R1hjU3pHdEIzbEpjenI3NTdjVkxYa0dwSS92?= =?utf-8?B?TlVvV25VZjVQeTR6Q2JmQmIwUUxRVEtOR2VyU1RkTHBsb2JUcVpKcG9SMTJ5?= =?utf-8?B?MTZSVTloYklHNkZDdE1WT1JwN3RLNHlPeUlvWitYdVFMazdhSkh2TWJ5UmQv?= =?utf-8?B?MEtyNTJ4VytFazRPQW9zOTh6MGxHVC9yN0VucHc4VUhsTUU3dGJDVCtFbDlp?= =?utf-8?B?NGR0UHhhZ3RXNGRyMHRrN2tJUTh0dG5nSFBONEUzbVBmQ2pkQm9LUjB2czBy?= =?utf-8?B?S1Q0QSswbG1SVm1rOWZ3VW1JYzdyZXJjeWpZUFp4c0U1OUZNTStpWFFkR2Zz?= =?utf-8?B?M1lRdWFiMHhhWHRnOTgwOVVud3ZZUnB5Vm02cmJwdFpGbURXUXpQZFhhb2po?= =?utf-8?B?TlY1R2Rnb1UrR05PQnZvaDFVZG5mdmpDNnVqWFE0dklEbTZFOU9ZcEVRSkUw?= =?utf-8?B?YkIrYTgzTk8vSUQ4OHB0bWFUcTRobkJjVlpPYm9VQlJ1YXBBYW9STUNPd0ht?= =?utf-8?B?T3BCSlhCWkVNcjJnMUs1VUs4T3hqMDRNdktFTVpSbkVHTTJjVTYyU2g2blBm?= =?utf-8?B?eUJqeDNaY2tMblAxY0NpUTYzYVh2M2grLzYzeEFZWDg2bXVLR3FqM1N2ZzZH?= =?utf-8?B?SjZ3eHM4TW9RNlZNUFNITEF6Nk8wT1FTaXh4UUtudXY3MmpYRnRGc1BmTU90?= =?utf-8?B?ODVIdTJUdG1jTlJteXhTTGpvdzgyNHp0RUd1M2FLd0ZlVmRSSm1TeUo4MSt3?= =?utf-8?B?ejJvWXdQaVIzbEdnL3A4T3JPQU42aFhkcTNuVzFnNi9zWW81TVE0MnJLdXhX?= =?utf-8?B?Z1pra2VXaXgvVW1pSHN4N3ljaGkvbGhHT3d2TTc3OWVjYlpOcTlmVTFsREFr?= =?utf-8?B?bGhjMUFNUiswRkFKbWZaNEs1SnRPUFRsODlrRDMyMWI5WTdONGFvTkRsK2V0?= =?utf-8?B?YzB0Vjlsdm5ISVlrQjl5SmRCeGY2NFZiemxEcDZQeGc3TUY3ekJEM1Z5L0o0?= =?utf-8?B?T0pkMGhIc2RxNy94U3M3MFZUbHZsZ2xhK1ZPeUFIQWlyUWdZR05aN0d1MEVq?= =?utf-8?B?NlJqMmpVN1F2V2FYVVpCVTZLb0tycHpRQ3VNeUJ3cGordjAvcm91U2pkdnlY?= =?utf-8?B?R2VDcVoySEcrenRzdStiVGVTcHQwczl2cWk4SnZlSHRNRkVrUEh0WGxBbkx4?= =?utf-8?B?K0k5cEp6cWVNRE5zbUJOakVabytJVGJaMDhQNWpXcEZpYnVHa2pXVExiQWhI?= =?utf-8?B?cWdRKzVrc0l4SnlNUXZuRFdJNUpUT3JPVmd5SVNYek5rMDZjNEprRExGQUJj?= =?utf-8?B?S1FuKzlrM1l1eU9sQ1RKYTdpL3lpQVNzVEJUS29LVzVONEdENmtXQWhjekRN?= =?utf-8?B?NDRGaXRuaDZ1QkNWQmp5TU5rU3pIUW1NalpqdEhGS2t2NjhrdGZNaUpXZ2xQ?= =?utf-8?B?Z2hBczNmdWpKbFJaRzhmbm9ZTWpPR0pJaTJYYklUTU0vZjhGQ3poR1g4SUZo?= =?utf-8?B?eS93ZFIwQkFhT3JGTzNTbVhNYlFnaENSQ2hLTXBCQXpMWHNscVlRSHgzZ08z?= =?utf-8?B?ZUtiYlpyeklaUTFHQlg4K0xyVlJ5MkNMbVNRb1RJRHZqTTJ4bVdDdyt5Ulc2?= =?utf-8?B?UnNGajFNYXZxN25ua1BJejJsdFlCbjhiblNxYXlMVUIrdnJmczBNRlV5SXA0?= =?utf-8?B?dVNoWGRKRG82U3FWQTg4WVFiY2lDenZ0ZldUNERDa3BKZTVpOG9KL0ZoUzha?= =?utf-8?Q?c7wMQn0vlVi6lze/JE=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR08MB5852.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(376014)(366016); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5517 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:102:8e::21]; domain=PR3PR08MB5852.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU2PEPF0001E9C1.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 33af8c9b-6b96-4a7a-db65-08dcac3443eb X-Microsoft-Antispam: BCL:0; ARA:13230040|36860700013|34020700016|376014|1800799024|35042699022|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Ui9UaVpINTdGbnZOQnArRkc1ODJrektFUjczQTJDOUFSRTMzRzV6cHZJRUl0?= =?utf-8?B?ZGFrSk81Sm52WDJqNkRKWjVyWTB1aVoxVFhHUkhLTHFHQ2Z1NU42TFNRc2dO?= =?utf-8?B?a2RXTE5uNFhvOXVZSlVDc1NZc0g4QXlUeEZnbVZqNjE1MElvZzd3VW1iQ2c4?= =?utf-8?B?bjJsaVpTaG5tUlduMU82V1VjSkpRcTN3VXhneG9CK2JxY0tvRHdMeXFqRUJm?= =?utf-8?B?eFlkWnplcXhiTWpGeHEvdW1jbWpPeUt1bzJFRWFpTHdDeDh6SjZiczB4aExl?= =?utf-8?B?OUN4a2pmRTBlWFg2dGQ2K0tZSmJOVERpQkNwZUs2OHZLekNDbVBHUFhoeGhy?= =?utf-8?B?Qitqd3J5L3VkRGYzZTcwMVI3TkUzcEkxYmNYN0pwbG1nc1REVmczejJuaTNG?= =?utf-8?B?OC90SEc3c3B3QlVQWWcvRWt2N3lmS1Q1dG5aOTlxVXgwOXZ4S0hZM1kyVmc2?= =?utf-8?B?Q1p5Y3BTcTE3dUo2OUsxZU1rQnBnVktKZnRGY2Z2SU1DRlhXMjFPZTVmbGIw?= =?utf-8?B?UDNXT1ptNGJQRks3TjdmZWhwT3JsbHo4a1lLYTU1dGx2cElmZTdvNkVkZFQ5?= =?utf-8?B?SmN6Q3NYUWRkVk5WVGdBMndrU09VVEVmMEMzOTg4aHhGNkZuTjRVL01UaFpO?= =?utf-8?B?aXpYTkZxZXRqU2RmMnB5TjBKUkg1eGJJV29ndnphZ3RBYWdtUHdIandmUXdC?= =?utf-8?B?aGQ1S09UczUzVkI2VXNPUFJuUjJnbDdjbWZGZHFkNFFIMjlWdGI5aFBsUS9W?= =?utf-8?B?QVRZaGdHeWtQRWhnbDdlak8xN1dOSVdvVXpjR2FrbC9mYkh5MGRaR1BMODVr?= =?utf-8?B?QUpEak1mZ0dURjM0ak1aaFRxOHBLazdmWXc5bm93cUNPYUIyM1BOMy9iVHp1?= =?utf-8?B?c3ZHaVhrMzZhZksyL0lOTUxPdFhFYkhVNnR1N0ZZY2NQOU0rMGpuYTE3eEhR?= =?utf-8?B?b05DWEp0RGt1c0M1TDJjYnpCOWVSanMwMU9lb01oa2J5UlZXelUyQ2lKREhp?= =?utf-8?B?UmNKSC95N2lTdWtXRXptV0o3Nk1YZStPNU8yZEUzYlZoL1o2aFdpcng1M0s3?= =?utf-8?B?b1BYcHZxamJFTjNkZHBwZlNlUDdyZnpkMG9jNEgyZmx3S3psRklWNDcreEg3?= =?utf-8?B?S3QzWHVPSW1sRDYwRnJSRER3ZTE2cHlHdzAvbm0zbmlBS2pFNW4vMTVURFcx?= =?utf-8?B?S00vSGljN0U5Y3VlbXVoYVRCNjEvakVaNEZqMmVmSnlNMnBxVU1LeGZEN25O?= =?utf-8?B?Zk9tZEhRVmZoTUhsL05GSDczZzZLQ25YdWt2N0hsY0VYbng1M05LZ3FtOVMv?= =?utf-8?B?S3k2ZGp0T2s0TFluVm9CNU1hcUJ2NGNYRnQ3cEJTSHpidkZqQTljTS80U3JS?= =?utf-8?B?eUZWT2NqNUJpcmlpMDdUK3ovUTBZZldpOThsS3ZNSy9NNUo5MU9IRkFUUVhJ?= =?utf-8?B?MWZOVUVMZGZ2bE5wUVp3cWtjVVdhVHF3RmpybmlMODU0dFdrWE95bE9KZEdI?= =?utf-8?B?VkJpOG1TclQwZlRHRFBvb21BaVVzSzhYNk5IV25CbXNwZE5UOW0zelNoMlNK?= =?utf-8?B?RDNWL1l4aE9BYTM3K2JhbStVUmh1OVRsNjY1RXlCeS8yLzU1ZlhkZGdhMUxJ?= =?utf-8?B?UW1Odyt4QjBRN1NkWEdmcStsZitCeDZQV0F5TEswREhqME1icHdBL1FMVDFr?= =?utf-8?B?Y2NRcjFHQklVU2RwR0FHcU82MDU4NUtFNjNsS3hKN2tZeXcxMXBqTXdWdU5h?= =?utf-8?B?MW5jd2U3RmlidTFWZU9ESzdzelF3Znl4ODBTVFYvN1V1M0JTdVEvbk1hOTJ5?= =?utf-8?B?TzZSdEJQdHI3YTN2SzZjOURpWjBXczdkcS9VVCtWS21BVlQrMkJqTWsybGdS?= =?utf-8?Q?RSNIedN9s0g7V?= 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)(36860700013)(34020700016)(376014)(1800799024)(35042699022)(82310400026); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2024 22:59:38.4192 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1ce0d36f-256c-4749-e373-08dcac344b77 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: DU2PEPF0001E9C1.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5617 X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FORGED_SPF_HELO, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.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/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. 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. 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. 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. Thoughts? >>> My theory at this point is that the following happens in the failing case: >>> - PTRACE_SETHBPREGS with address 0x4004e2 >>> - compat_arch_ptrace >>> - compat_ptrace_sethbpregs >>> - compat_ptrace_hbp_set >>> - ptrace_hbp_set_addr >>> - ptrace_hbp_get_initialised_bp >>> - ptrace_hbp_create >>> - /* Initialise fields to sane defaults >>>       (i.e. values that will pass validation).  */ >>>    attr.bp_len = HW_BREAKPOINT_LEN_4; >> >> >> The default starts as a 4-byte breakpoint, but is supposed to be adjusted later on to 2 bytes. If this isn't happening, I think we have a bug somewhere. >> > > Agreed, you could frame that as a kernel bug.  It would be good to known whether the kernel developers agree with that assessment. > >>> - attr.bp_addr = 0x4004e2; >>> - modify_user_hw_breakpoint >>> - modify_user_hw_breakpoint_check >>> - hw_breakpoint_parse >>> - hw_breakpoint_arch_parse >>> - case is_compat_bp(bp) >>> - offset = 2; >>> - fallthrough to default >>> - return -EINVAL >>> >>> In short, we try to validate: >>> - attr.bp_len == HW_BREAKPOINT_LEN_4 && attr.bp_addr == 0x4004e2 >>> and fail. >>> >>> By reversing the order, we validate: >>> - attr.bp_len == HW_BREAKPOINT_LEN_2 && attr.bp_addr == 0, and then >>> - attr.bp_len == HW_BREAKPOINT_LEN_2 && attr.bp_addr == 0x4004e2 >>> which both succeed. >> >> Why do we have HW_BREAKPOINT_LEN_2 above while the first case has HW_BREAKPOINT_LEN_4? >> > > Well, because we reversed the order of the two ptrace calls. > > So, in the original case, the first call to ptrace uses the default bp_len (HW_BREAKPOINT_LEN_4) and the actual address (0x4004e2), which fails. > > And in the reversed order case, the first call to ptrace uses the default address (0x0) and the actual bp_len (HW_BREAKPOINT_LEN_2). > > [ With "default" meaning, as set by ptrace_hbp_create, and "actual", as set by the ptrace calls. ] > >>> >>> So, my questions at this point are: >>> - is this a problem limited to aarch64 32-bit mode, or does it also >>>    occur for native 32-bit arm? >> >> I'm not sure at this point. They are two separate code bases, but it is probably reasonable to assume the compat layer of aarch64 was based on the >> original 32-bit arm code. Checking hw_breakpoint_arch_parse for arm, it does seem fairly similar. >> > > I also observed that they're very similar. > >>> - is this a kernel bug? >> >> Potentially, if it is assuming a length that is not correct. >> >>> - if this is a kernel bug, is there a workaround we can use? >>> - if this is not a kernel bug, is this because gdb is writing the >>>    Breakpoint Register Pair in the wrong order? >> >> I don't think we have a specific order to write things, but if it is a bug that arises from a specific order of commands, we could potentially >> work around it. >> > > OK, I'm currently testing that approach. > > Thanks, > - Tom > >>> >>> Thanks, >>> - Tom >>> >>>>> >>>>> Thanks, >>>>> - Tom >>>>> >>>>>>> >>>>>>> >>>>>>>> (gdb) PASS: gdb.base/hbreak.exp: hbreak >>>>>>>> continue^M >>>>>>>> Continuing.^M >>>>>>>> Unexpected error setting breakpoint: Invalid argument.^M >>>>>>>> (gdb) FAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak >>>>>>>> ... >>>>>>>> due to this call in arm_linux_nat_target::low_prepare_to_resume: >>>>>>>> ... >>>>>>>>              if (ptrace (PTRACE_SETHBPREGS, pid, >>>>>>>>                  (PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0) >>>>>>>>                perror_with_name (_("Unexpected error setting breakpoint")); >>>>>>>> ... >>>>>>>> >>>>>>>> This problem does not happen if instead we use a 4-byte aligned address. >>>>>>>> >>>>>>>> I'm not sure if this is simply unsupported or if there's a kernel bug of some >>>>>>>> sort, but I don't see what gdb can do about this. >>>>>>>> >>>>>>>> Tentatively mark this as xfail. >>>>>>>> >>>>>>>> Tested on aarch64-linux. >>>>>>>> --- >>>>>>>>     gdb/testsuite/gdb.base/hbreak.exp | 40 ++++++++++++++++++++++++++----- >>>>>>>>     1 file changed, 34 insertions(+), 6 deletions(-) >>>>>>>> >>>>>>>> diff --git a/gdb/testsuite/gdb.base/hbreak.exp b/gdb/testsuite/gdb.base/hbreak.exp >>>>>>>> index 73a3e2afb67..b140257a23e 100644 >>>>>>>> --- a/gdb/testsuite/gdb.base/hbreak.exp >>>>>>>> +++ b/gdb/testsuite/gdb.base/hbreak.exp >>>>>>>> @@ -27,10 +27,38 @@ if ![runto_main] { >>>>>>>>       set breakline [gdb_get_line_number "break-at-exit"] >>>>>>>>     -gdb_test "hbreak ${srcfile}:${breakline}" \ >>>>>>>> -     "Hardware assisted breakpoint \[0-9\]+ at 0x\[0-9a-f\]+: file .*${srcfile}, line ${breakline}\\." \ >>>>>>>> -     "hbreak" >>>>>>>> +set re_loc "file \[^\r\n\]*$srcfile, line $breakline" >>>>>>>> +set re_dot [string_to_regexp .] >>>>>>>>     -gdb_test "continue" \ >>>>>>>> -     "Continuing\\.\[ \r\n\]+Breakpoint \[0-9\]+, .*break-at-exit.*" \ >>>>>>>> -     "continue to break-at-exit after hbreak" >>>>>>>> +set addr 0x0 >>>>>>>> +gdb_test_multiple "hbreak ${srcfile}:${breakline}" "hbreak" { >>>>>>>> +    -re -wrap "Hardware assisted breakpoint $decimal at ($hex): $re_loc$re_dot" { >>>>>>>> +    set addr $expect_out(1,string) >>>>>>>> +    pass $gdb_test_name >>>>>>>> +    } >>>>>>>> +} >>>>>>>> + >>>>>>>> +set have_xfail 0 >>>>>>>> +if { [istarget arm*-*-*] } { >>>>>>>> +    # When running 32-bit userland on aarch64 kernel, thumb instructions that >>>>>>>> +    # are not 4-byte aligned may not be supported for setting a hardware >>>>>>>> +    # breakpoint on. >>>>>>>> +    set have_xfail [expr ($addr & 0x2) == 2] >>>>>>>> +} >>>>>>>> + >>>>>>>> +set re_xfail \ >>>>>>>> +    [string_to_regexp \ >>>>>>>> +     "Unexpected error setting breakpoint: Invalid argument."] >>>>>>>> + >>>>>>>> +gdb_test_multiple "continue" "continue to break-at-exit after hbreak" { >>>>>>>> +    -re -wrap "Continuing\\.\[ \r\n\]+Breakpoint \[0-9\]+, .*break-at-exit.*" { >>>>>>>> +    pass $gdb_test_name >>>>>>>> +    } >>>>>>>> +    -re -wrap $re_xfail { >>>>>>>> +    if { $have_xfail } { >>>>>>>> +        xfail $gdb_test_name >>>>>>>> +    } else { >>>>>>>> +        fail $gdb_test_name >>>>>>>> +    } >>>>>>>> +    } >>>>>>>> +} >>>>>>>> >>>>>>>> base-commit: 0ed152c5c6b3c72fc505b331ed77e08b438d643a >>>>>>> >>>>>> >>>>>> In any case, I agree gdb doesn't have a better way to deal with it. >>>>>> >>>>>> Approved-By: Luis Machado >>>>> >>>> >>> >> >