From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id y6NMB5tCo2b7PTIAWB0awg (envelope-from ) for ; Fri, 26 Jul 2024 02:30:51 -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=KzKmXx5S; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=KzKmXx5S; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 0EBD81E0D0; Fri, 26 Jul 2024 02:30:51 -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 D30711E030 for ; Fri, 26 Jul 2024 02:30:48 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4374C3858433 for ; Fri, 26 Jul 2024 06:30:48 +0000 (GMT) Received: from EUR02-DB5-obe.outbound.protection.outlook.com (mail-db5eur02on2076.outbound.protection.outlook.com [40.107.249.76]) by sourceware.org (Postfix) with ESMTPS id 027E93858D20 for ; Fri, 26 Jul 2024 06:30:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 027E93858D20 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 027E93858D20 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.249.76 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1721975424; cv=pass; b=ovFwrStA+kykEf8UKBNC2mdpg21GdzYqZhBKKgczh3lTBqkLs+6hlq6+mNwcAPPog9bIo/CPVonw6wfm1Z/2fsvQU6w6IyrW0pjPM2xetFsrjqHDHrQMnvfYKs2ArZm7gvsLKJ/KI6d0vG60nrovE2NCj9n9raaqpmwxSr6Ki1Y= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1721975424; c=relaxed/simple; bh=17XuTOCVzzpt06oRlVQdNgEk7oESlylSbggtwf+QS+Q=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=R0ymvB5zhjutqnQMvlKXsTQTHOfzqdRYI7GMJgxy33/Gi2rf+u/oxSbHa39LT3sSOozO5BATkaAF/oARS7w2XZJq11SMuVEAMkgkk1QGdjHY6JqcrQC+Xu2dbIyJaBDCPktLBeteLRQpxArfr2n3HfUvZnOaqc3TtrCLf57cGbk= ARC-Authentication-Results: i=3; server2.sourceware.org ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=M8WOCuUFt2Y8oCfI6jIu6udvsTONdofohT6XgzcQvAYos6UsSIcPVu73CZxMuE9r1qy3xCaX3TGaBfUCAzJYXu7zBKqeWF3szXs8RIQ9ALXpwSwFKx2r205ZJakKVHQsW4ispI5uBj1wNJZuRjmr9JjL7umV/6ZedTF+4LnkUr3hSQGPGEQUbzny+8VW26rEzWSM3Nt5fCsDTMqvE0mAJqAWmMOXKRjjoD64t/6Oi7Ehnw2p8sYH6/1+VLgCP6VLc0UlsdPWVebuimrI0waSmt5HqWhioocyS4CAsVUMErAOwQUD7FVgyFK+Skqtp56f7kJzVvnO6Vy1qaIVMEfFKA== 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=+4CIcBu74rCO8ZLwR0w6e8FvaE926t1QDXZtd7W3SKA=; b=Be3ZY7krzByP/60OT37ASykbDTvOcFI1CsSiOwcB5O/GvY/sbf+q+nFhfjV6ygcDci7hehwVyeNzD576IwsT0wE4xGIiO6sysriJz9Mug59QSXnymPdgqc8gTGIZ9IC4bi/xmN/3w/4M0TaG0wD3HUIpfu3/IQmikzwz01xCtLUSh9X66oMGxfDdPAffiOg+iQNNPTHg9jZ5YgeHwBga/nGPjKpOWxIQkN7h1nF8ZCcF/BHZjpOy0qQbC9nnmq2ifwvNjlzzyi1fD0N4X/ASyPw1XPc+jzUfqXs9gry9dAQwEspJmzYgTIIJdOfvU0rzlbyuSIerulv5OPsEudet5A== 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=+4CIcBu74rCO8ZLwR0w6e8FvaE926t1QDXZtd7W3SKA=; b=KzKmXx5S+D1LIozUb0NkDqpnSf1WF70gYxesDmNFzSZYEZC4SXAksIX9ync0bxDF1wbnKX+EMxjgaL9HiK11k9hNQo9EpSjaTs4EmvkXVc/RFE+ICn3UJGsCI47ns7qNKZh96z1uPknETR1HBeQNw0+bFFzXNzZigOXhP3rmfSM= Received: from DU6P191CA0021.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:540::26) by AM0PR08MB5426.eurprd08.prod.outlook.com (2603:10a6:208:184::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.29; Fri, 26 Jul 2024 06:30:16 +0000 Received: from DB5PEPF00014B8B.eurprd02.prod.outlook.com (2603:10a6:10:540:cafe::12) by DU6P191CA0021.outlook.office365.com (2603:10a6:10:540::26) 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 06:30:16 +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 DB5PEPF00014B8B.mail.protection.outlook.com (10.167.8.199) 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 06:30:16 +0000 Received: ("Tessian outbound ab09e808a502:v365"); Fri, 26 Jul 2024 06:30:16 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 83cb79e6c5e41a2a X-CR-MTA-TID: 64aa7808 Received: from Lf66f924a1ebc.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8F2EF57C-FDFC-4597-9B6D-828A5398ED9C.1; Fri, 26 Jul 2024 06:30:09 +0000 Received: from EUR02-AM0-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id Lf66f924a1ebc.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 26 Jul 2024 06:30:09 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TGNjtPFOXGqscViVFt25QlkbtyOfDtwqbSbfZr4yYZWvs6ukJxwvz3f6p7p6IP3TbADCa6x1+Rof/akcsmNPqHuoYkxxaS1U22WIBLNusuFJ5RPUQILOeFrrcXEPwI/gd8Kt++hiAKai2oXGkdX8jbZpOHqahjqMLDPNFOHt+3rXKIePgzx5StA4Fo9CbYEKLF5zGGTflld1ln3+IEKuQSYBrqwAz8mbVraLaCbJVf2R6FFwuLO60A2wuM+0C4QkvtlEC43wxYOqred7d3TMJ8Z7M+gdxLMP7UFxtU2ExMCj8rDXsAlyBfUK50rHalVB45/VDBQ+zkIqbFeZCwpAHQ== 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=+4CIcBu74rCO8ZLwR0w6e8FvaE926t1QDXZtd7W3SKA=; b=frSe3vupkl2JP5w/ioTjjOFY94g2u1N57hHhqgechkjPBpk03XDdmlSWBHIhwfjqe7/56bUO+n8yb8grqFbnigTo8jxp7EUr59/lnlNKlbyCwI06zTxgxUaguRtEeqm+I59DVLsdJBTOU/krFP4t/vJl3oAx04QhLT3ZdfdyP08hij33SUKLjgfYI/f1oKYBp5K+urnYrqy9DR66SSiM8oc5O6gPruwDR3+28QyqKXXunsJewxHov6els6CjBsjLUPkLZUvRZGq2IJ7K0NQHKIu84gij1SoZUlwyzZ5U1Rw48NahGBKw/6Ea8yoNZ8qhsNgJPcAoRoRmp3yfxz3AOA== 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=+4CIcBu74rCO8ZLwR0w6e8FvaE926t1QDXZtd7W3SKA=; b=KzKmXx5S+D1LIozUb0NkDqpnSf1WF70gYxesDmNFzSZYEZC4SXAksIX9ync0bxDF1wbnKX+EMxjgaL9HiK11k9hNQo9EpSjaTs4EmvkXVc/RFE+ICn3UJGsCI47ns7qNKZh96z1uPknETR1HBeQNw0+bFFzXNzZigOXhP3rmfSM= 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 AM9PR08MB5906.eurprd08.prod.outlook.com (2603:10a6:20b:285::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.28; Fri, 26 Jul 2024 06:30:05 +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 06:30:05 +0000 Message-ID: Date: Fri, 26 Jul 2024 07:30:03 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] [gdb/testsuite] Add xfail in gdb.base/hbreak.exp 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> Content-Language: en-US From: Luis Machado In-Reply-To: <7a3e65ee-af3a-4134-8719-cbace79afd92@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0184.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:311::10) To AM8PR08MB5842.eurprd08.prod.outlook.com (2603:10a6:20b:1d7::17) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: AM8PR08MB5842:EE_|AM9PR08MB5906:EE_|DB5PEPF00014B8B:EE_|AM0PR08MB5426:EE_ X-MS-Office365-Filtering-Correlation-Id: 96663710-a87b-47a0-c4a6-08dcad3c699d x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|366016|1800799024; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?MDMvZlhKditEUFpOdlk3eWh0dzh5NmtUZkd0RjJzOFNYNXVIak8vc0ZWUlUz?= =?utf-8?B?emFxaCtXNnhtV1JmMG83T1RNc2p3VjVTaWJncy9Rd0VkZWhqOTlhMG9hK0FR?= =?utf-8?B?WFYxR0lEQndKSlZLaHVXb1BrdzBmQ2pGdGdQZnhYQjNBQXR3NDU1YlpTK1FX?= =?utf-8?B?V2hNK1Y0TURNMlpNSzJlZUVTNms0bWo0NVJGMjJxUHBnUzdzYWorczM3VXdx?= =?utf-8?B?c2RuRzNMdFNTeEh4dU5MbzMrNU5uVktVb0Q0QnNQV2lGRXhLU25mV2tzS3Nl?= =?utf-8?B?S3YvWk1JcmhSK3dGbzg2NkpQZFFZSC9Wb0dEVzRlMG1maG5sUStRaHZpOHky?= =?utf-8?B?b09YSGZuNUFPSXJzQ2JGLy9zditWdVgvNU9hU2lKdng0R1crd1J3MzU5dFk5?= =?utf-8?B?dllUMGl2bWZDdDcrYnhJNnJhT0ZQRFBsSVRMelFCRzJlMmxVb2hwK0tlL0lB?= =?utf-8?B?eXV0dC9LeUFrYjBBMTVEYXRtbTlvR3A1VENZTi83aUEvbHA0Y2h3eUhWTHVF?= =?utf-8?B?d2xHYTB0cnFrak1vWXNxT01meWtMU3B0N1JUZTFZMTNMK3QxL0J6SWpPR1Z0?= =?utf-8?B?azVkUzR5WVh3NzkrYm40WXZZZTlGWTBJSll3VXU0TWFPY2w4SlZ0ckgzYmRM?= =?utf-8?B?dG11enZ6elN4ZkYzT1FqY1RDWkNVTHhXM1RCcXk5bUZLWm1WRFhmaFEwUXVk?= =?utf-8?B?MWoyVWJXTUNncGYzUWY5WVVvTTd2QlpsZ0ZqM0hSYVlOUDVBMmI0SW1ZYU8y?= =?utf-8?B?NElKdGRTaERkY2hQT0FEQ1VxUzVBbFJEMGRTb2I3NUV5aG9UQVBvcXNTdDho?= =?utf-8?B?dll6WmFKZEViUi9wRmFIUGZqRGNXTDNvQTFZRXJ2a2VhYUFaVVdVckx5cENu?= =?utf-8?B?YnhYY21Gd3huOWs5akY4K0tPKzlRYmFvZzRDOEF1QkhJNHZaUGpiOUNsK1dn?= =?utf-8?B?ODlMZVowb2FMOGkyMmlsNU4vbEgvOU4waGxMTi9QdTBqRTZ5QUJVcG44ZEtI?= =?utf-8?B?SkxpQi9sZ0dFa3NZYm9nOElTcjZGR0gybFQvWVdDbWRUZDBRa3ZmbVFyaWk5?= =?utf-8?B?Q3p0ZllsdkJFbDBJUVU2OEFKSVZYTHFDYVlERzkvZDFSYzB6WVV0bnd4SSs4?= =?utf-8?B?dGZ0V3hDNXpORDMxL0xxVFVSSWpNMmZGNnFwMUp4QUpmclRWeW9BMXBKVGlJ?= =?utf-8?B?MHBsamQ1Q2k3WGpJNlBjMk00TW12U1RXem5JYXZxWndZZ29ZOCtyUm50ZllE?= =?utf-8?B?S1JIaC9nRFhqZ1F4d1Q2L3FlVENERXdDczEwblNSRTYwd3EzWlBNcEg3WFlG?= =?utf-8?B?cWhsYWw1Q2FxMzBoV3BBNzMrbzBQOHdXcWZLNVMycnlHM0crQmltblJ5UDJL?= =?utf-8?B?SlFNbVdIOG4wV2l5U2I1NjZ2N1Z3MFNyY3BsVVgxSEdtMGVOQWJJWTFjcVA4?= =?utf-8?B?OGlWaTNvNENHaVk2Y2QwMkJYUEdTQVZmZzFhSXQwVXJOOTMwUnZzLzM0RHRo?= =?utf-8?B?RXMwWnNxR3pCR3VFVFJoL2FPeFk2THo2NmFXZjg4THpkcXV2RVFWWnhMcGFD?= =?utf-8?B?TmN1a2l6WUkvSWxpdkVDMnBnMDVVazJrVVQ3SWJ6ZUxOQzlWbW9tUHBueU1F?= =?utf-8?B?dUhveFRnc0lQUzd1b1ZvZnQwVnM2d3RmQ3VYaTRZdEdrYjJ5Y2t1bmJkcmk5?= =?utf-8?B?V3N3VENpNDg3dnFGelpBdHpMNWFaRXpLSXZTLzFSZ283TG9JMlVvMHpQQndt?= =?utf-8?Q?NZbq5cQGOuQ8rNEewk=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)(376014)(366016)(1800799024); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB5906 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: DB5PEPF00014B8B.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: f98bfd0a-ba46-4b48-1b30-08dcad3c6334 X-Microsoft-Antispam: BCL:0; ARA:13230040|82310400026|35042699022|36860700013|34020700016|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?THZUcDd5TXRrbGhzcys1VVhnSXhjR3dwa3l3RXh0cFpNTXQ3TG9MYU12OFVO?= =?utf-8?B?WGdvamdieHp3eEh2eVhEZEtYTUo1akZsYWtGN3ZWa09iRy9IL3BQN0x3MkhE?= =?utf-8?B?YXJDMEliblpMUE05d01MZ2dNNVUvaWtmWk9Ic0YwSTZPa0YvOFlsSU5yMDEz?= =?utf-8?B?eGlrcTA1OFR5WURhMUhWSDhucmRzcCtiSUxQODRtemcvTWNYS05tZHZRUUdm?= =?utf-8?B?RWNVdHlBQmJ0bGV3NTBxMjVOdGNXdFNLRHlxWk8rRnpKZzREdWh5MWVYQjVk?= =?utf-8?B?dGFreWRMM3BNV3p1VmhSVm5nWWFrNnE2T0xhTVdtNjFKa1pNY1JWaFYwT2U0?= =?utf-8?B?emVkVENNMjljVnl6RUh3MmErd0Y0WGF5VDRaWGRBSFBpRjZLQXhndjY3UUNs?= =?utf-8?B?ajE0NHhJWHZBcDVhRXFxSGlqMExLWG9EK3AzeU5uM2hTMkdKa1BubS9Va0dH?= =?utf-8?B?TURkQjRIQ2JFZmRDQy9WcG5yMWgrQTJQY3VxQkNNaGpFVmJSSlR6NDAyVlM5?= =?utf-8?B?RlJtbmlUS0RkU0svTkZJQ0JLbjBhOGtYUUprTFdSbXEzUHhNZ1RmMXlEdjdv?= =?utf-8?B?S0JZYTZueFUvdmorQVl4Z3NUUkt6SzYyQ2V2bjJqR3dnS3hQcW1SRFJVek9t?= =?utf-8?B?T0FGNm9hM1gzQ3RSVUMyMXMySERuTVlxUDdZUDBRaTRwTTd6TUgvY2dmbUtS?= =?utf-8?B?eFdBMC96dkwzYTF3cWZDL3pXU0luQVVJTWJFZG42bHhVUXNOY2N6ZktBQ0lG?= =?utf-8?B?d2luRDJtMCtiTEt3MkJSRjBuTXNwRzh0NTQrY0V3WjVKSEV3aVJNd3JHQjVK?= =?utf-8?B?UG1VazdaVzl2UGJQY0dHVVE1clhFM2NZOUhoUElUZHNaNHc4b1J6T0VDOHVD?= =?utf-8?B?YjJqWWdlK1ZUdXNQN2lhV2w5Qm01ZjEvRXNZWmJrbmJHbCtCamI2SmYwbmlk?= =?utf-8?B?ZDVOYzF4RXBuc1ZqZWJxcHJZdDdNRGNiWE9SRkZxVDZiRjM2dmV6TnQwUE5H?= =?utf-8?B?bDN1dmhUN295bmZrWE1QTmlCV3Z0UlJzVkxDbk5BS2dxQ0E1UmZCSk9ESGM0?= =?utf-8?B?bnpVQzNReExJZlEwSmw5K0Q2aXFNK0xDYUhDcU1jT3VhYnptK3gySGlKbXFr?= =?utf-8?B?YWpWVmNHWG04MXBIREdzV1NNNHF2bmtsOGdJSzFwRklGUkRhUXAxdHltRTJK?= =?utf-8?B?ZGZ2blM5UHRmeUVEZ3Z2cXVCeFRDVC9YOURXUEJZTU4xSFBoa3EybHJHV1cx?= =?utf-8?B?ejY0TTBidDRHSkVUaWpDUnpYdDFtOGdHM2YyUjljTWFsdFBxZHR6bXZEMnc1?= =?utf-8?B?MWdqU0V4aFY3dkhoeVpqdEJiRVgwd0w5eVdKTnU3NWI2TTVidjVhc1V3SDVG?= =?utf-8?B?M3FZbTh5UW1zVHZieUFsOXhaVlZFeDZuUG1lTUNMdEpVUFc4ZEZTYWdTR0hS?= =?utf-8?B?T2ZtUmJZdFU5KzNYTHh6clB3ZG5yQnd0U2RqVWdyazIxbjEwYWJYa0NIY2FM?= =?utf-8?B?N2k4dlJ4TnYzVVF0SUUxc3Z3bUV4WmNWWTFKQm05QnBGMGZ4eTR6Sk5NNlJo?= =?utf-8?B?NWdZQlNrSnRLdjNsOTNGa1hCMWtaNmJuVitnTU1qRmM1THZpQ01PZTlqVUIw?= =?utf-8?B?S0tzTXBCZzUrKzBnSmoydDFFcWQ4OW8wWkdiOUZIUG9xckhBemxVcERISnkv?= =?utf-8?B?dW9HQSthSFIrVUwyaDRnTUlQSmpQNHkwbTQxSXpQMGxyN0tsbGVnYUh0amJi?= =?utf-8?B?SmJyTnRCdlRDWkxRRTlYNnkva3NleFFYY08rMllWM0cvRENWUHU3TnphWFd5?= =?utf-8?B?V2dlTEd2cE44ZmtpOEJ5cVN3WVdvOWpVMDRhZ0dPYzdZYlNEZEtMeXRlaU8z?= =?utf-8?Q?yuM64fUdF9esI?= 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)(82310400026)(35042699022)(36860700013)(34020700016)(376014)(1800799024); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jul 2024 06:30:16.1357 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 96663710-a87b-47a0-c4a6-08dcad3c699d 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: DB5PEPF00014B8B.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5426 X-Spam-Status: No, score=-10.0 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/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. I'm in the process of booting a 32-bit kernel to check what is the situation on 32-bit arm. > > Thanks, > - Tom > > >>> >>> Thanks, >>> - Tom >>> >>>> 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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >