From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Sa0jNz5d1Wgz9xIAWB0awg (envelope-from ) for ; Thu, 25 Sep 2025 11:18:22 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=efficios.com header.i=@efficios.com header.a=rsa-sha256 header.s=selector1 header.b=JgS9yEXA; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id DBBA81E0BA; Thu, 25 Sep 2025 11:18:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 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 19A891E047 for ; Thu, 25 Sep 2025 11:18:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B4B50385840F for ; Thu, 25 Sep 2025 15:18:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B4B50385840F Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=efficios.com header.i=@efficios.com header.a=rsa-sha256 header.s=selector1 header.b=JgS9yEXA Received: from YQZPR01CU011.outbound.protection.outlook.com (mail-canadaeastazon11020074.outbound.protection.outlook.com [52.101.191.74]) by sourceware.org (Postfix) with ESMTPS id 72DB63858402 for ; Thu, 25 Sep 2025 15:17:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 72DB63858402 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=efficios.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 72DB63858402 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=52.101.191.74 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1758813456; cv=pass; b=qd7Ils3geeqSX7e5U5QRcqetxDTv06emSmHSK2mwxD6gbkptWSiRZOOTO3pq3PcQqpXJbfEZj1ssUM1P/QYTRRuts7IPUaQ30jrgIAwZlyqI86wFpx/wchs8ewR1y/5XR7Ey/ZWeK139tHaSxFENDIMQTyGaNTg9+UA5p+3+rAA= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1758813456; c=relaxed/simple; bh=8lYwwhCvaQVKCiyc9c8L12+N/tFeB39gEoSCY1vcp14=; h=DKIM-Signature:Message-ID:Date:To:Subject:From:MIME-Version; b=SRH9orhUmCpVb+lYSZTJFuNSQVLJi9UtjNSju+5srxzIkGE50K8rxVaiqz9klt1lZeMWpTFdpVEYDpyLoZ+BAIFWb6gGDFXofET8UDfFfnalh2Yaz1AcUbpHsPQyvPdesyeZ33MuQD8embaqOIBZzQvMYcNT9gy+b+8qJnC/ZW0= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 72DB63858402 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Nxwjc6tN9EGcgLqevM1UCnv1Z1OZvo19eRBJvuWdpGLs5vr22zVTv5XUqsi/40Y3reUZvrhwWXS7m0FIcDUpVOE7Db+FFHSmQeth/4IxL0pmlLmtcREptcxZQUVa2Y+QFrKbAAfVe59OOCBQJ5HCDRW/mJpYMXHiet1u1l4pB5y1+MQEVz3gg4amA2o0GeZlEmzQGo0Cj6CfO6Tgs+IPRJnV3MGtN9aZ8OvJ2kmsACZdPdhODqpLDYGEatWKubzVmTsN4KwB+rwLA5WFhb/F0XVfRn2CmPudFz3OCjsO6hbEdMmBvT6rfvsl6Acba9Pyc5zSBTB/20Z7+llltjCZoQ== 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=RsL6DFy1dI44qnSltfqPN6/r1jbXPqqKMwuPIukIqK8=; b=A9Qu3avovIf4ALLWUH/8j2xqEj/gpsse1lYhbIt0xZ6Mg13dApN1I85Q3wA0H++EbFzTnPdq2iUg060XZhZsp9SR8WLby4f9SNXWCyK7S1IQnWdS7OPThaS8einSbDtvoB5tToGI5Gb7cxBFij6PSdFPkfKhAZnmgWr68cDzLbTpRaDd0ktIitYUK7EdTUPAjGQnk40V0Rmtf0HlEEljgb5qgqfwcgEpkuwghlrP0x0pUL8+7XlB8p6djCoO+44Hs9UIt0JqhPwswC4/vYL01zoFgAlG7+z7G5P6Qaj/D9S4HBURyHWKun2uDkLcZiN4gPWg7hV5SrqpyOkcR3YDXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=efficios.com; dmarc=pass action=none header.from=efficios.com; dkim=pass header.d=efficios.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RsL6DFy1dI44qnSltfqPN6/r1jbXPqqKMwuPIukIqK8=; b=JgS9yEXAJE1tisZXZxQDmgvTHcvdNwFCOrYwTO4dN71zsNgRC8CRl1lIKuKyd/5Ik7DRaUmuQjJvoSo/NQZNXF4OZSiMXmmLFQff2PFAV9i36ePE2rV8cz466O00pe5sP87Cm6lntyr/mn9VuXqJhDxvaXK4XyMr4GRYjBnAFabwjxphKeff5F4zXKao3/5Xx1tar3z+Q+kEUhmJV8oF9m2bN4K38iq+jc/3eIpYHc6V7xM9c2f+Nlh/v6JtMxSfaeAydrsxxNPuTwjHeLEH5jVyKoPkp/IJX+x8h/ZmXlW7l+rZVwirmw7sR+nMMVzOQROokM3IHuoMpq8GSqIdHA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=efficios.com; Received: from YT3PR01MB6392.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:73::5) by YT3PR01MB6244.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:67::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.11; Thu, 25 Sep 2025 15:17:31 +0000 Received: from YT3PR01MB6392.CANPRD01.PROD.OUTLOOK.COM ([fe80::fc93:a379:fc8e:439d]) by YT3PR01MB6392.CANPRD01.PROD.OUTLOOK.COM ([fe80::fc93:a379:fc8e:439d%5]) with mapi id 15.20.9160.010; Thu, 25 Sep 2025 15:17:30 +0000 Content-Type: multipart/alternative; boundary="------------2PCaGa75NMxXcZEo0h0JRFOZ" Message-ID: <7febb0c1-7bbd-45d5-8ebe-91c34bb4a6ce@efficios.com> Date: Thu, 25 Sep 2025 11:16:57 -0400 User-Agent: Mozilla Thunderbird To: aburgess@redhat.com Cc: gdb-patches@sourceware.org, simark@simark.ca References: Subject: Re: [PATCH] gdb: ensure bp_location::section is set correct to avoid an assert Content-Language: fr From: =?UTF-8?Q?S=C3=A9bastien_Darche?= In-Reply-To: X-ClientProxiedBy: YQXPR0101CA0063.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:14::40) To YT3PR01MB6392.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:73::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: YT3PR01MB6392:EE_|YT3PR01MB6244:EE_ X-MS-Office365-Filtering-Correlation-Id: 14df5e76-0f17-4cc0-bc24-08ddfc46a4ef X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|366016|1800799024|376014|13003099007|8096899003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?c2ppY2NvZ2NxUHJXUFk1UlFXUjJ4anlZSG9FNmgxdHJVaTFQRW5kOE1vaWx3?= =?utf-8?B?VWJxRlVKK1UxN2FIZFNuTGJTanozWnZGYnpEbzhrd1Q1Q2RpQ2FBREY4dFhE?= =?utf-8?B?NVRJR2tvQ0lvV1pTNlV0ZU11N1JUYUdoc0dVKy9aMDZJZURKSlRzOXgyNElT?= =?utf-8?B?SzNZaXJNYlV3aHNVMFlBYVM0Wkt3MkpuZ3lhajBmcUpXNkpLcTFlbWRiaWN4?= =?utf-8?B?S1ZSTHJjRTFaLzVta0VKaDFyc25xWGdPZnZzS003ZzJJRENGSlkwZ0Q0eW1G?= =?utf-8?B?SzBOSmdjZ0U2UHYrbXlrVVlvU1R4OFZTTW56R3J3cWFxTjRTcTNvdCtCMEZ2?= =?utf-8?B?MWkzSmNXY2F3VlE5ZHIxRjdyZmJ2TE14OHhwNmw3Q3VweHNhcTU5UE1aMVVj?= =?utf-8?B?dmVBdTZOSFArTHduM1NTTmxhZ0Job2x3eFE4RnQyRlYwbFpzTWZLSUUxSXla?= =?utf-8?B?QVhTUFVzOTJUWjNOelI4MFdqMWVlazFmYkJMNVVLTEVQTnFRVGxXVTVxdFpZ?= =?utf-8?B?b21TUDhyb0d2aHFLbTVlWnlJSmFRSE80Qzc4am5ZYWdyOVEzTUJmdnlZSUs4?= =?utf-8?B?eGU5d1dOTUZsbVZuZE54V2puTW03U0w2cnF3Y1IrK1BaeFpBaGxpNGg5QTFx?= =?utf-8?B?Qzh1M1AyOVY0SlJ2c3RTcitXMFZHME9FamtaQnBBWHEyT0ZaN2NheWFDNHY5?= =?utf-8?B?ODg3QTVhUkh0amFVeXJDdG9pdWJLbEMyL2k3ODArYklBYnlxQXFlY1AraUVV?= =?utf-8?B?S0lBcjVrYUZtZURyNFVVNUNXZzZTZjk5YVJGUlhvYlYzQmpBV2hTendSVXVG?= =?utf-8?B?NnVsclVaWWg4aUxHQnFteFE3cVNnRnlTdHM4akI5OVRUN2pUZWtRRUxDN3RO?= =?utf-8?B?b2FXclpuby9PUjFmLzQ5Z1pWZ29OeUpQSnlkTVRxZkd0TGllMTFBa05DaXRu?= =?utf-8?B?OG9XcFliMkRBdzIwTjJzdVZyeDlQU3BBUWNrdHFFK1kzOXk3UmpZZjR3djEr?= =?utf-8?B?SkppOWJDbnVIWDgvUEx4Mk9mZy9CUVNxeW5XWkNmRTZlamFHblBXc1FxV2Jj?= =?utf-8?B?OVNmdnZhMkNyL1NXZjg0RUdCVmV2SXpVQkE0aVlocVNPZ0VvdjBETlV6OHd0?= =?utf-8?B?T29sY0hxVm94K3ZXZHMxbDQ2S0k3elRuSWpzbzZHeldwQ2tONlRRS2ZRcEhK?= =?utf-8?B?ZFRiSU9jQWwxcFduU2RjQlBsRW5WaXhxZUp6VmllM3lCdnhuOWlqTUVkWGNo?= =?utf-8?B?SXd2OVFadzUvYm5uc3dCamZhbCsxRDVZTzRtcU1CYUlWaWRCUHhZVWRvQkZh?= =?utf-8?B?bmU0bmRrK0VCcmI3V2IyNVc5OWZvOWxhZSt0OVpLK0JJeHN3cDIzVjRSY2Fu?= =?utf-8?B?MnhobzFOZ1YxZ3ZvZGVIUmRjRTA2K285eXBXYUsrem10UTNwUy9zdnR4amdw?= =?utf-8?B?Y3dYVk95Z2Y2MGhmOXRIRXBGZzBlMzJ6WmpsR3BibXUvVDU1cTJyaDIreHNK?= =?utf-8?B?dUJPSzRIMTVrNkRQV0xyaml6UU0vWGxsWlI5YUdNWTNMaVd3R0U1aFJYR1Rn?= =?utf-8?B?cWxCaTA5WDVLZlJ2ZXp2THVYZjFJekttSlVsbUhhc0FHTWVZSFZIejUvM3JW?= =?utf-8?B?R25PWFljRy93cFZkSFN2L0ppa3FETEhxTFRTcDBrektIblRCYVNraVVvN2JJ?= =?utf-8?B?d0pLMEl6MkV1cXcxT3FkQ3NqTjRkbEwvek5oYnM4Q09tZjhUQUdrUGhhMmgr?= =?utf-8?B?WTRzYTJDOFpSMktpMEdkVDhhblJlV2YyU29Fdkd4NTAxVEdpTTVXazN0Qjhp?= =?utf-8?Q?xadijuBDMqnKU5dFQ2wtcDgfr09V7OtgIqZiI=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YT3PR01MB6392.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(376014)(13003099007)(8096899003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VzFVM044N0RXdmdBU2E0YWZZZ1RWMmRlM2p0Zjg2MTNDSjNMb2s0NS84MUk5?= =?utf-8?B?Vm5jVU9hUDhOL3c3ck4rT1ArRzNJZHRWa05KbHRyTWxEYzJ2N1hyZkM3WnBD?= =?utf-8?B?b0oyMXhuVDJiOS95RmtMRTJaUzhNZVJ0UU1wQlYwckdHQlJmcEp2ajUvZEsy?= =?utf-8?B?cDIyRC85T1Vlc1haQjlBcWhaVUNLWHB0cExXOEx2M01DZm5sV2o1YXh2YUZV?= =?utf-8?B?eVUyd1QwVCt4d3RrMG5aVVBGdjRTVjFHME1YRjMxZVFJMFdZbWIvTElIM3gv?= =?utf-8?B?UXBJMjVNWlkwcDhSajlsckxCZDZlQ1Z6bkYrQTVmbXNoNnpQMjBXTGdhL2Y0?= =?utf-8?B?SGJHdy92Y2ROc0VvVUw3aW9uSjAzS1dCcmVqNUw4T2pGQUduaHZBbk9WOXZl?= =?utf-8?B?cEpwNnFGSDV3UXdyckhFMWRKV1hvOVd6WEczdExhZmFQeHZxdnVHUEtFM3U2?= =?utf-8?B?cXYrSWNVZVNwREV2U1JNQlptbGNSa2NobU9DdEUzR2NIdUsyU1RDMm53TWw4?= =?utf-8?B?UTNpaFF6Vm04YXlHQWZ0UW5nWVFjNWhHM21CUSt1NGM1R01ldEFWbDJoVkZV?= =?utf-8?B?dW0rcHBpcmRjTTRRRVZJdHRiRWh5SW5lR2dXcGpLUjlyUDJ0d0U1Z0tRVk9x?= =?utf-8?B?ZFJobHJkcVlscFBBZEd4TUgxcTlTNVZTWkZNWlBWRHNvclR6RzE0OVBjUmR1?= =?utf-8?B?S0JRWXNYQkhKVlRyQlNWbEdCdDlZS29XVXNzQ1NQb0NIU0N0MnFqQVI2cXJj?= =?utf-8?B?SUYxdVZHOUJxMldoUUFMZTdneVFSTC8rYTczVUpnSDJJeFRNSnQ5RXN6ZU93?= =?utf-8?B?WTF0a0NRdGVHNEVvZTZVeVhkQzlxMWVVR0dyL2U5RkJFUGJxdWNmS253eFoz?= =?utf-8?B?Rjl4M1dpN2ZaYkN1WCtKWHJDR0loMWhHdmNHQWxQajdLVTdOUmh4OS9XY2h4?= =?utf-8?B?T1NLNXIvdkxLcEpCRVY4QzVIUFlGNHZ1YWVXcitNeWhIUitxbERONU4wenJm?= =?utf-8?B?czlyTTUrQ3VuSmtRZ3RnNHJwbVRIbUUwNGZIeUw3SDlLRllkOTcyUGRVdlU5?= =?utf-8?B?OUNOdTNBT3ZMTkRubmRnZXpuTG8rMGdYT2JBVzdyeEczcFZhQ0lRM1IwUnZx?= =?utf-8?B?YTUyOGxoc2s4aThBTExnMXRQandyeUZIVVhGenlOZitxVTBjZEFITFhEMWxB?= =?utf-8?B?Uk1QaHFyQlpzTS9ITW5wdFIyeStTMG1sdmZlM1lKd0E3SHhIU0JFQVoyT2sy?= =?utf-8?B?NVVkSDQ1NThrajBYN3lrR3ZZUlJaU3FCdmVmU3IxVkVFR3cxekVxeE1wTHJz?= =?utf-8?B?Z1hGd2oxbS9UNFprZlBya3VHWlFScmpXWURxcWdHWUdUSko4YTRZRjZpQkxB?= =?utf-8?B?ak01cnJLczBnR1lic3IzaDVULzVMNG9qSnd4Yk5qQnRKVDBkK3lLWlZiR1dp?= =?utf-8?B?dFNwSFRYREpXTzlEbUZkM0l2cnhCWHNzZnZGeXBvY0kydkt3dS80ajk1aEJt?= =?utf-8?B?d3puSTNQWkVRWjl5M0UyVjZ5VXdZQjB6UmVBTVVOQ0ltT3FCeXFtZHV0Mkc2?= =?utf-8?B?RHJqcU05eUNsVmhydENGeFRPbkNUNkNoR1JyelVzcVBoRS9DblJFUnArZnlE?= =?utf-8?B?VE4rYmtLUzlFbmRsMm1pb3JJa1lGWWwrTDh5d2V1bHZmQmhzT2lKNm10RFJ2?= =?utf-8?B?Rkd2dXc5ZndTb25ubE53U0krVWFIdGk2SHdXTzFHNXJ2ZkxrNkppVzNCcDZU?= =?utf-8?B?N0ZVckFHQWVkbXJvalMzdm91QWVoQ0plNDg5ZHQrVEt1N3ZJYkp2OGFMN0Vk?= =?utf-8?B?NGZ6N21FUFVXUzkzcXBYemhKVi83dlZROEpSWUJjeVRHUVJzUWtBNHZwcytJ?= =?utf-8?B?aE1NVWdVc3I0d1hDdGdCSkNJQjhyTWhPNXRlRU5IcDZINEdIQ3grRG1obFpQ?= =?utf-8?B?ME5HY0NtMlJ3TS8rOEVUcjUzdnR4NVA0Vi9PaGxaTk1YMXNuQVJQRGhtMVdI?= =?utf-8?B?bTBGNmR0OEtBeURKYlF5OUlwaVNNOXJNNFZJVUNNLzg4eGxNQm16LzZEeDUz?= =?utf-8?B?aGp0UjVBTUdhS255bjhJY0hlemZEaDAzQVlRenZaNFIxd0d1S0RMaFNYY3Jt?= =?utf-8?Q?yc6VGfVy8e+oxfdspKoXJ5Ueh?= X-OriginatorOrg: efficios.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14df5e76-0f17-4cc0-bc24-08ddfc46a4ef X-MS-Exchange-CrossTenant-AuthSource: YT3PR01MB6392.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2025 15:17:30.5590 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4f278736-4ab6-415c-957e-1f55336bd31e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: CSgcJHUwonqgCLb9yBtvFDgfmsLLGjB5AcuHsHOExNpk89/s+Fwg+7WjhOOK0MbLWHX7LvfT/jQocKvNvEz5fw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT3PR01MB6244 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 --------------2PCaGa75NMxXcZEo0h0JRFOZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andrew, We've noticed a regression caused by this patch on one of the amdgpu tests (namely gdb.rocm/displaced-stepping.exp). This test attempts to insert a breakpoint at the beginning of a GPU kernel, step, then proceed to the end of the test. It would appear the breakpoint is inserted but not hit by the GPU. Upon investigating why the breakpoint is not set the way it should be, I've found that code_breakpoint::add_location relies on the section being set to deduce the proper gdbarch, by calling get_sal_arch (breakpoint.c:8615). If the sal section is not set, then the gdbarch is set by default to the breakpoint gdbarch, which in our case is the host's gdbarch. This causes problem down the road leading to the breakpoint not being hit. A quick fix to the problem would be to call find_pc_section() to assign the proper section to the pc, *after* checking for find_pc_overlay : diff --git a/gdb/linespec.c b/gdb/linespec.c index e634bf22f3c..4a4d178085c 100644 --- a/gdb/linespec.c +++ b/gdb/linespec.c @@ -4120,6 +4120,10 @@ minsym_found (struct linespec_state *self, struct objfile *objfile,       debugging, it should reflect the SAL's pc value.  */    sal.section = find_pc_overlay (sal.pc); +  if (sal.section == nullptr) { +    sal.section = find_pc_section (sal.pc); +  } +    if (self->maybe_add_address (objfile->pspace (), sal.pc))      add_sal_to_sals (self, result, &sal, msymbol->natural_name (), false);  } This ensures that minsym_found() finds the proper pc (instead of the resolver, for ifuncs, just like your patch intended), then assigns the section corresponding to that pc. Ensuring that sal.section is consistent to the pc is, in my opinion, a more appropriate solution than leaving its contents empty for the time being. Modifying the other places where the section is needed (or expected to be null) may require some further investigation. > I think what we need to do is update minsym_found to just use > find_pc_overlay, which is how the symtab_and_line::section is set in > most other cases.  What this actually means in practise is that the > section field will be set to NULL (see find_pc_overlay in symfile.c). > But given that this is how the section is computed in most other > cases, I don't see why it should be especially problematic for this > case.  In reality, I think this just means that the section is > calculated via a call to find_pc_section when it's needed, as an > example, see lookup_minimal_symbol_by_pc_section (minsyms.c). > > I do wonder if we should be doing better when creating the > symtab_and_line, and insist that the section be calculated correctly > at that point, but I really don't want to open that can of worms right > now, so I think just changing minsym_found to "do it just like > everyone else" should be good enough. Admittedly, this means thinking about *when* sections are stored in the sal. Let me know what you think about this problem and if you think of another approach. Best, Sébastien --------------2PCaGa75NMxXcZEo0h0JRFOZ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Andrew,

We've noticed a regression caused by this patch on one of the amdgpu
tests (namely gdb.rocm/displaced-stepping.exp). This test attempts
to insert a breakpoint at the beginning of a GPU kernel, step, then
proceed to the end of the test. It would appear the breakpoint is
inserted but not hit by the GPU.


Upon investigating why the breakpoint is not set the way it should be,
I've found that code_breakpoint::add_location relies on the section
being set to deduce the proper gdbarch, by calling get_sal_arch
(breakpoint.c:8615). If the sal section is not set, then the gdbarch is
set by default to the breakpoint gdbarch, which in our case is the host's
gdbarch. This causes problem down the road leading to the breakpoint not
being hit.
A quick fix to the problem would be to call find_pc_section() to assign
the proper section to the pc, *after* checking for find_pc_overlay :


diff --git a/gdb/linespec.c b/gdb/linespec.c
index e634bf22f3c..4a4d178085c 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -4120,6 +4120,10 @@ minsym_found (struct linespec_state *self, struct objfile *objfile,
      debugging, it should reflect the SAL's pc value.  */
   sal.section = find_pc_overlay (sal.pc);

+  if (sal.section == nullptr) {
+    sal.section = find_pc_section (sal.pc);
+  }
+
   if (self->maybe_add_address (objfile->pspace (), sal.pc))
     add_sal_to_sals (self, result, &sal, msymbol->natural_name (), false);
 }


This ensures that minsym_found() finds the proper pc (instead of the
resolver, for ifuncs, just like your patch intended), then assigns
the section corresponding to that pc. Ensuring that sal.section is
consistent to the pc is, in my opinion, a more appropriate solution
than leaving its contents empty for the time being. Modifying the
other places where the section is needed (or expected to be null) may
require some further investigation.

I think what we need to do is update minsym_found to just use
find_pc_overlay, which is how the symtab_and_line::section is set in
most other cases.  What this actually means in practise is that the
section field will be set to NULL (see find_pc_overlay in symfile.c).
But given that this is how the section is computed in most other
cases, I don't see why it should be especially problematic for this
case.  In reality, I think this just means that the section is
calculated via a call to find_pc_section when it's needed, as an
example, see lookup_minimal_symbol_by_pc_section (minsyms.c).

I do wonder if we should be doing better when creating the
symtab_and_line, and insist that the section be calculated correctly
at that point, but I really don't want to open that can of worms right
now, so I think just changing minsym_found to "do it just like
everyone else" should be good enough.

Admittedly, this means thinking about *when* sections are stored
in the sal. Let me know what you think about this problem and if
you think of another approach.


Best,
Sébastien


--------------2PCaGa75NMxXcZEo0h0JRFOZ--