From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Q1UuAxN9R2fAFAIAWB0awg (envelope-from ) for ; Wed, 27 Nov 2024 15:12:03 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=HOTMAIL.DE header.i=@HOTMAIL.DE header.a=rsa-sha256 header.s=selector1 header.b=WI+aS+3h; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D25311E097; Wed, 27 Nov 2024 15:12:02 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FORGED_MUA_MOZILLA,FREEMAIL_FROM, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 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 9DBA91E05C for ; Wed, 27 Nov 2024 15:12:00 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0D7143858435 for ; Wed, 27 Nov 2024 20:12:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0D7143858435 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=HOTMAIL.DE header.i=@HOTMAIL.DE header.a=rsa-sha256 header.s=selector1 header.b=WI+aS+3h Received: from EUR03-AM7-obe.outbound.protection.outlook.com (mail-am7eur03olkn20805.outbound.protection.outlook.com [IPv6:2a01:111:f403:2e0e::805]) by sourceware.org (Postfix) with ESMTPS id 04A9D3858415 for ; Wed, 27 Nov 2024 20:11:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 04A9D3858415 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=hotmail.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hotmail.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 04A9D3858415 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2a01:111:f403:2e0e::805 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1732738281; cv=pass; b=cqjnQYM0PzJRqZ1Z9ZC3QjTWF9oSPuXmh1PmNxXaVeQOqlIAIxkjuJpLPZYowdAbdtc/kY1MB2WyBHEC4d2hO8byh96Y6k70LyVKvLWoK+Mo6gNlNLlF41Ndacl54NksmmzrIxRwh91OxtFqFDILYHxVgw4+akZOU27HjvWd2PI= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1732738281; c=relaxed/simple; bh=AHp0ZiDLRboxMeQxeo/qAQ7gjnMRufCfeezTBuJgj3k=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=sp9gUcTlki6RAxSghHKuTLYQCR39OnpyBJ7b5mdAhOlxp7v/6+Fx6b3HnOH4OK8d63NJcdEGzAkEv+J907B8rCod7UOT3VE4kn5Iwg5tz513iHR2UWUPSRqKzxBm1uzo8SwlVOrnhAVcvM5oPf+kCQUgKY+zan3PdYoxYgwORZ8= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 04A9D3858415 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qTLAcDg8wKk9x0Z708rtaeqK2nJrn6o7Lw0g4rrCoZK0wYV4uDAyTB12vuihSEoapSkilfZWm62zcVOlIYI8q9hL2E4YIulCLfVsmior2NhJ1J3tZ3o8+PNgmPYnWbi5wm4QdW6HQEJp2PSCYtCNFN+LgQ/9C1ef2EcP7afNxbDdyDpIi2gFkGERTe2nfWLecXb9s4o+XkkA0POlPBsFxfEMp71MiOc8Lb9CWIJEXdE7y03W9rstRaOTqW/vizHKfwzt2Sg4g0eMkgAAxWUPlfKJqwU8VsgdzHvvT4mmUQoiwd0OgUtoctqWQ9GfmQvorV5Qy64hn6vC6qFgZl+yTQ== 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=jL5iQUONFDZLapyEE6fS9ihh8NAOTz8CwnRlG1u9km4=; b=qZXEPFMroRX8zH6mEMfXRnGEegksWmfzRd5EOSZ0Wr3I60tYTAITr+rz5E9eR0qyAhGZRaWed1kF9iUHRtxwqLCh5rGVoJ7tA6jLmpYKufOBsjYZjzkhTCrc+BTYFsKV4mLeINh7CGNqOG+lK/BTZ8ZY4Ci9mzNAKSrD2DTbs40s36YjCHpHSWTXeFA7i3pVouokX8H7xRFqBc2LJnPSyAJUA4ZaLfF5s7XKQ7Kk7hwVc5GQAS4SKn13Jjmc39mAQFXsp6OCQ6xezO3zp5cxBIwHaCRj/p23YfG7czL6xiYV4a6FSc6tZcnowTohi+MHMwTAfSyUnjnmu3K+L8j7lg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HOTMAIL.DE; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jL5iQUONFDZLapyEE6fS9ihh8NAOTz8CwnRlG1u9km4=; b=WI+aS+3hlbhWZZ8dvz/7ESoNnNpIn7X/LWAAq5XOQiokKC6lonM3Vot2e3O1aIpni/6fw73DintEYJczu8CSoLHywkRgkd19kvrGF9xJ5aFw0nbhTTCE0gwHi4ahMpqFZQCoulXMkuR3ZxhXhDky1hogb43WEAzf6X4zBqxrYMuZtBEAz7P6VZYBuQWz8EX5wDXRaPrf8F4R75HmNQQqQ9PFwBFgmHZX0PClV82ut1RUjSJzWRvurFNfbR0T5NFk2+T/03t2vC636gG84aStORC2aGrT7Ya8Zv14QMYw23uY39RZcGsLZ7x/NiRpp+OrWGT6x574LctkMxReLH2dVw== Received: from DU2PR08MB10263.eurprd08.prod.outlook.com (2603:10a6:10:491::6) by PAWPR08MB11157.eurprd08.prod.outlook.com (2603:10a6:102:46c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8182.20; Wed, 27 Nov 2024 20:11:16 +0000 Received: from DU2PR08MB10263.eurprd08.prod.outlook.com ([fe80::c2a3:fed5:607f:20c8]) by DU2PR08MB10263.eurprd08.prod.outlook.com ([fe80::c2a3:fed5:607f:20c8%5]) with mapi id 15.20.8207.010; Wed, 27 Nov 2024 20:11:16 +0000 Message-ID: Date: Wed, 27 Nov 2024 21:12:22 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: handle DW_AT_entry_pc pointing at an empty sub-range To: Andrew Burgess , gdb-patches@sourceware.org References: <34cfe440ffd0e53843bfaf92494d29a6951fa9fd.1732114887.git.aburgess@redhat.com> <87y11bw6p3.fsf@redhat.com> <877c8rmlm2.fsf@redhat.com> <87bjy1lwcn.fsf@redhat.com> Content-Language: en-US From: Bernd Edlinger In-Reply-To: <87bjy1lwcn.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR0P281CA0116.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a8::18) To DU2PR08MB10263.eurprd08.prod.outlook.com (2603:10a6:10:491::6) X-Microsoft-Original-Message-ID: <4490fc27-494e-43fe-a0c1-bfbbce7e794f@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR08MB10263:EE_|PAWPR08MB11157:EE_ X-MS-Office365-Filtering-Correlation-Id: 5fe16937-95a9-4f43-18d9-08dd0f1fa613 X-Microsoft-Antispam: BCL:0; ARA:14566002|6090799003|7092599003|461199028|19110799003|5072599009|8060799006|15080799006|56899033|440099028|3412199025; X-Microsoft-Antispam-Message-Info: =?utf-8?B?clVDcFFCQSs2Y3UwR3VVTk5ZVzZMWnZGeGRTZi9kdUVOZjJDZDJkT0FQelRi?= =?utf-8?B?TnNiRDhYRUR1QlRBTURsTzd4ODRlTmtKN3JCNEFwSDZDVTJkQ2JiVjVvNkFB?= =?utf-8?B?bWJ2d1pKWnBhTGx3NWxHb2dpVWpZeHVXRCtidVJhWWNROWp0cTFRU28yT2dK?= =?utf-8?B?akhmd3gzV3c1NWlibk5kNVNIalNxRzgySXlnbkJDNmhrdG1VU1lWZkJ1SUhV?= =?utf-8?B?NGo1dk1FN2QxcmtWMkhvTVJOS3ZGRCtSWFNsS0wwTGUybW9mcmFUWDhRbkls?= =?utf-8?B?RnFZU3VHdUltQjZqeFZSR08wTDhSMm9ONjM5ZEdsN2IxL0l6SjU3cG05WTEr?= =?utf-8?B?ZnIzQ2tpNXpYbHVWMytKUXMydTdMQmY1QUsvZXhmajgzREtnMDRlZnZiZFBB?= =?utf-8?B?b3hnb2hXUkZZUXowWVNZeXJub3lkSW9aVGRua2Y1Tzltazd4UnNxcVVxQjVV?= =?utf-8?B?a0M1QnRaME1qTDFYVUVlOEU2eXRnRzhKOTF2MERQSi9aMTIwdWV6cDVjc2Nr?= =?utf-8?B?dDJ0d3g4b0pFcWdndXZKa3BycWtkMWxLY3lTYnVHTnNoSDVlYXhEYWZiQkRS?= =?utf-8?B?ZjVhckUza3hnZWE0cCs5RktEdy9jMW1wL1Y0MXBtdG5CdWZUakVGRndsWHh5?= =?utf-8?B?MGxFNDkwZHZqSlMwS29wbXVmdjhmaFkyQU9aNkl1aWlNUUZHT2hyZmVQOUNL?= =?utf-8?B?ekhad1JaM0w2bnM5cjVZcVR6aGZvMUhNbFlZakg2dTBCY0ZPSHZTNUJCOWE4?= =?utf-8?B?Skd4NkhIVlNOSmdrQ3VwNjVscXJTd2h0NlBiTnlDMUl5Q3VTTW50SG90VnJL?= =?utf-8?B?ZkV1VG9oclYxMFMwQmFtT0MxVGxIbGpYenNDY0JNcEFSU2hoMjNnWHhwNng3?= =?utf-8?B?cnVRNDE0ZEJPR1Q1dmNqNmo0OXFiTEJjYzBaU0szbitoRU1YandKMHd1WEds?= =?utf-8?B?WFJlS1E3OW04MEVtN3FUblZQV1JWWk00T2tXVmpHTjVwTjJpZnR5a1ZZSW04?= =?utf-8?B?NFh4QUVPY0JBV3BjT3lLckRvdzJHVTM2NjdiTHAydldNSjFsOGZmWURUcWt1?= =?utf-8?B?TmY3d0RUV3ZhS0JiSHJwNm5uTGxvVTQ3TllGVUxBeFRYOUc5STlES0wrZnZ0?= =?utf-8?B?ZHoxWHRxR2JyODdUVm8vMW0vZWh1UE1UUmdDQkdFak1YWGZ4MDJldnZQOEpy?= =?utf-8?B?VkhnL3VBTE0rZnVNRU8vV0h1alpNUXloc2NqU2JxT3BKSmRKZUFia09BZ1Z3?= =?utf-8?B?VWhvYm1BbUdVS3c2V1BNN3FGd3NjZ3hoNHlHL2NCM3pGNWtCeDM5NGhnM3BU?= =?utf-8?B?YUJmeVhHWUJ5dk5tY2FnbHNITitjL2RrZDlwNW5uMTdBZU5uWStCaUNWL001?= =?utf-8?B?S0Z3Z05iUTlZaEF5UDRwU2xGTHhHS1lXT2lITTE3Z2MyY2QxSzJMSnluRUY1?= =?utf-8?Q?EfCac+Rk?= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c2xhYTNwSVZzMnlwVkhPdlNDYS9aM21kbDlVOC9OUkVOZFpWeGNCWmRmbTJj?= =?utf-8?B?Sk1kcU1wa0E1Tk9zeEVTaUo1Y0d4SWFROUJWUXNDOUNOMGUra3pKUXA0QmtP?= =?utf-8?B?Vmp1Rlh5VXZ6K2RmU1FtY1I1K0o2VkNHYmpJdnhkVWUyTmwwUFBPTjcvcDds?= =?utf-8?B?aXVMQkVwbWp0d0dxRGo2aytwUGJudjBnV3YxTTViRmpDL2FHLzZzb0NOVkJB?= =?utf-8?B?NTdyVW5vUFV1MTZ5RVhwTElWK0x5RVd2UnZGNTZxd0l1R0RIWDhORU13d2ZY?= =?utf-8?B?eGhWYjdPT3lvakVUYzdMRG9kcy91Wk9uVWV6M28rNU56S2ZvNGE1b0hUd1c2?= =?utf-8?B?Wm92aE9XY3Y4bHBmVTRHMGVuUW11MUg1MCtzNlZSdC9mSEN1cDVRSnZWcG5W?= =?utf-8?B?UUlOMXF1b1lOczFmYTVwQ095V1pKRnpaSlB6UkwzdDNoQ2ptMnp3ZERZWmtE?= =?utf-8?B?c0REODQrMkFxRmd5Zmk5ZThqZ2VlcDJsRWprRnlkR2wzd0dNZ3dOTFh2dFNk?= =?utf-8?B?MW5ob2tXcEVHUmFVVHJ4clh3TSt3NlJsRmI1bHFWNzNnMmdSd0RHbWE4MXE5?= =?utf-8?B?YzVuaHZEcTFaWE9Ec1QrNkN6RmJQZEkwS1QxQVBoYUxhWU9ITHVDQlFQalJ0?= =?utf-8?B?UVJkTDZXNmU2WHlsd2RSQ0tOQVdlUi9kcXlEb25zNmZ6MEU5VWdPSFU3QXRV?= =?utf-8?B?NTZGN3RxT0d2ZnVLTkIzclFyQXZHallqUElRRFU3aVRHakZ0WlM5SStsek5C?= =?utf-8?B?ejFsTVYrZDV5b29TZUFlazVHQ0pPTXphZVgwVVVUbnFxT3FCK2hWampCNk5F?= =?utf-8?B?K3pFeGFRVDE2cDVoQzEyZjdieHY4ME9QV3lqZnFMS3FvcWdZMVROQzBWbjdJ?= =?utf-8?B?Z25OZzdTWXNjUEM0M3paMENJbnJ5ZkxWVytMbzdjQTRlT2NLbFd3Vnp5dGxh?= =?utf-8?B?QVp0MEx0V0FrKzQyVVoySHEvbk9zQzJuT2xUcitIN1lRQUdkNkdWb1RuK01k?= =?utf-8?B?NGxzcGYyYVRvaHV3NFRmUVlpdlFyaENCcUcvRXBKZjRDNFdSb0ViaWxPQk03?= =?utf-8?B?V3gra1pvWGNKMWo2SkVMemptODA1TmlZODVmYTdiYmR2SlFia1JCTEZyTzh2?= =?utf-8?B?bHhXU2cxbkpFaGIvcmVVc1FKMForeFVnc243WVA5OUhpQ0lKZzhGZ2JjcUhE?= =?utf-8?B?UW1vZVBuYmlqQVRvVE10bGo1Zy9NV0JnRjIrTHZTdk5UcmFaZXR2U0FtMmQ0?= =?utf-8?B?QjRBUjhSRkRrbXQ1cGwxVmFzdWFVRk5Kemt3cmNIRVQ4eHdSMC9RRjFXd2ZO?= =?utf-8?B?cjh3OUo2ZjZjckNlTUwva3JiazR2TjhiUjVJcGdhaUkrRFdwS1J4K282MFpj?= =?utf-8?B?Q1NaY3dYSDdrYkg4YkswUmdKNjVidU1FaXlKdWdJY2tIOEdFem1veXpsWTFS?= =?utf-8?B?czFkaGk0YVRESkZSMFJLK0FaUjVzVUtaN0JWL3lZcDYrSHJabE9qdEJOSDB0?= =?utf-8?B?NTRGT1Q3d1BJVWMwSWRmYXZxbWx0bDZSa1JhOWp5cGdwSjhFVVQyTE95TXFh?= =?utf-8?B?bVpvZGhjUGlJM1lUSmVWWnFzdFZLcWtONFd0eFdJem9oMS9GQnFXZjUzdjEx?= =?utf-8?B?UlcyczFNSlBZeElUTi9ZbSs3a1BHYVRRQTZQUWdaUEw2d1VZeWpiZTczU3dS?= =?utf-8?B?NlNLbjl6THZOYkllamFFRDBKbXFzbkNVUnhSWmhkNnRqK2lrRElkVVR3aFZW?= =?utf-8?Q?Zwl/ISsrERMkDxz6fmVlnemTI4wPBZwZas5s3xp?= X-OriginatorOrg: sct-15-20-7719-20-msonline-outlook-de33f.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 5fe16937-95a9-4f43-18d9-08dd0f1fa613 X-MS-Exchange-CrossTenant-AuthSource: DU2PR08MB10263.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Nov 2024 20:11:16.4085 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB11157 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 11/26/24 18:48, Andrew Burgess wrote: > Bernd Edlinger writes: > >> On 11/25/24 15:30, Andrew Burgess wrote: >>> Bernd Edlinger writes: >>> >>>> Okay, I just wanted to point out that in my opinion the debug info which >>>> points at the end of a sub-range is not incorrect, just maybe on a border >>>> line, where the dwarf spec is unclear. So you should not say: >>>> "after all, the DWARF spec is clear that such a range covers no code." >>>> >>>> But there are obviously not only cases where the entry_pc points at >>>> an empty sub-range, but also in very rare cases the entry_pc points at >>>> the end of a non-empty sub-range. >>>> So could you please change the check in dwarf2_addr_in_block_ranges >>>> from addr >= start && addr < end to addr >= start && addr <= end. >>> >>> Could you expand on why you believe that the DWARF spec is unclear in >>> this regard. I came to my conclusion based on this text within the >>> DWARF-5 specification, section 2.17.3 Non-Contiguous Address Ranges: >>> >>> Bounded range. This kind of entry defines an address range that is >>> included in the range list. The starting address is the lowest address >>> of the address range. The ending address is the address of the first >>> location past the highest address of the address range >>> >>> This seems pretty clear (to me) that the end address is not part of the >>> region covered by a range. >>> >> >> Yes, but on the other hand, when we look at line table entries, each has a >> PC and a VIEW number, and even the DW_AT_entry_pc has a DW_AT_GNU_entry_view, >> just the range list does not have a view number, and that is inconsistent >> with the concept of location views. >> >> Consider as a simple example an inline function: >> >> int f(int x) >> { >> x++; >> return x; >> } >> >> it will most likely just be compiled into one "inc eax" or similar, >> and of course you may want to set a break point on the return statement, >> to inspect 'x' after the increment, but that will be on 'pc == end' ! >> >> But if the location view number would not be missing from the rnglist >> it would be obvious whether the corresponding view number is still within >> subroutine and not outside. So in my opinion it is a defect in the >> specification that it does not reflect this use case. > > You make an interesting argument that the specification is deficient. > But I'm not sure how this helps with this discussion. I would like to > avoid derailing this conversation with discussion of missing DWARF > features. > >> >>> Additionally, if we start to accept 'addr == end' then this is going to >>> cause problems elsewhere. GDB will place a b/p at the 'end' address, >>> but when GDB then performs block lookup, GDB will not return the block >>> we expect, and so GDB will not report the inferior as having stopped in >>> the scope that the user expects. >>> >> >> No, because this is exactly what the core of my patch does, admittedly >> I also modified the block lookup code a bit, to handle that case. >> So I strongly disagree here: we have to accept 'addr == end' and other >> corner cases, otherwise my patch won't work in the end, regardless of in >> how many small bug-fixes it can be split up, because it depends exactly >> on not ignoring any information while parsing the debug info. > > But accepting 'addr == end' only works if you also change the block > lookup mechanism, which isn't part of this patch. This patch is based > on the state of block lookup as it exists today. > > I've included a patch below which applies on top of this patch (i.e. the > one this thread is about), it changes the check to accept 'addr == end' > as you suggest. It also updates the test so that an inline function > (bar) has DW_AT_entry_pc point at the 'end' address of a non-empty > sub-range. > > Here's a GDB session with that patch applied: > > (gdb) b bar > Breakpoint 1 at 0x401137 > (gdb) r > Starting program: /tmp/gdb/testsuite/outputs/gdb.dwarf2/dw2-entry-pc-in-empty-range/dw2-entry-pc-in-empty-range-4 > > Breakpoint 1, 0x0000000000401137 in foo () > (gdb) maintenance info blocks > Blocks at 0x401137: > from objfile: [(objfile *) 0x3b11720] /tmp/gdb/testsuite/outputs/gdb.dwarf2/dw2-entry-pc-in-empty-range/dw2-entry-pc-in-empty-range-4 > > [(block *) 0x357e680] 0x401106..0x401185 > entry pc: 0x401106 > is global block > symbol count: 1 > is contiguous > [(block *) 0x357e630] 0x401106..0x401185 > entry pc: 0x401106 > is static block > is contiguous > [(block *) 0x357e5e0] 0x401106..0x401185 > entry pc: 0x401106 > function: foo > is contiguous > (gdb) > > As you can see, GDB stops at an address which doesn't then resolve to > the bar block. > Ah, okay, thanks for the test case I looked into it and tried it out with a gdb built with my patch. A breakpoint an an empty subrange works as expected, but indeed a breakpoint at the end of a non-empty subrange does behave as you described. But with real code examples a break point at the end of a non-empty subrange does work, and that is because my "heuristic" which does the magic, uses weak line-table entries near the end of a subrange to determine what to do here. So because the test case does not have a line table at all, the test case is not realistic in that aspect, and does not tell you what happens here in a real world example. So a patch that allows for start <= addr && addr <= end should be applied, probably with a line table that looks more like a real line table especially at the end of a subrange, then the test should probably work out of the box. But it is okay to do that after the rest of the series is applied. > If/when the block lookup code is changed as you propose then this > restriction (addr < end) can be relaxed. But it doesn't make sense to > merge the relaxed restriction, without the block lookup changes. > > And no, I don't see that as a reason to merge all of the changes at > once. I think splitting the original large change into many small steps > is the correct approach. And sometimes that will mean that we check > something in, and then revise it in a later commit. That's not a > problem with this approach, it's an advantage of this approach. It > makes it clearer how we got to the final destination. And each step is > smaller, and easier to review. This is the preferred approach for GDB > patches. > > I feel that, as the author of the original large change, you're looking > ahead and you're frustrated that this code isn't inline with how you > feel the code should finally look. But just because I hope we can check > this code in first, doesn't mean that I will prevent this code being > changed later on. As GDB evolves (e.g. if the block lookup code > changes) then I'm happy for this code to evolve with it. > > To (I hope) offer you some confidence, I have, on my machine, created a > branch with this patch (without the 'addr == end' change), followed by > the next two patches I plan to post (once this is merged), and then, on > top of that, I have rebased your original series. This includes all of > your original tests completely unmodified. > > I have tested this merge with gcc versions 14.2.0, 13.3.0, 12.2.0, > 11.5.0, 10.5.0, 9.5.0, 9.3.1, 8.4.0, 8.1.0, and in all cases, all of > your original tests pass. I'd rather not post this merged branch just > yet, as I'm worried that this might derail review of this patch even > more, I really don't want to start discussing the next patches before > they are even posted, but if it's the only way to move this patch > forward then I could share the branch. I do plan to make this unified > branch available when I post the next two patches I'd like to upstream, > as I think it will actually help at that point. > > My hope is that you will be willing to accept this change on the > understanding that this code might need to be modified in the future. > > For my part I also accept that this code might need to change in the > future. > Well okay, please go ahead. Thanks Bernd. > Thanks, > Andrew > > --- > > ### Patch to show 'addr == end' doesn't work (yet) ### > > diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c > index c178b13d96d..60daf032036 100644 > --- a/gdb/dwarf2/read.c > +++ b/gdb/dwarf2/read.c > @@ -11351,7 +11351,7 @@ dwarf2_addr_in_block_ranges (CORE_ADDR addr, struct block *block) > /* Check if ADDR is within any of the block's sub-ranges. */ > for (const blockrange &br : block->ranges ()) > { > - if (addr >= br.start () && addr < br.end ()) > + if (addr >= br.start () && addr <= br.end ()) > return true; > } > > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-entry-pc-in-empty-range.exp b/gdb/testsuite/gdb.dwarf2/dw2-entry-pc-in-empty-range.exp > index 79b1783b2ec..9e4fb781a8d 100644 > --- a/gdb/testsuite/gdb.dwarf2/dw2-entry-pc-in-empty-range.exp > +++ b/gdb/testsuite/gdb.dwarf2/dw2-entry-pc-in-empty-range.exp > @@ -179,8 +179,8 @@ proc run_test { entry_label dwarf_version } { > " $::foo_5\\.\\.$::foo_6"] > } > > -foreach_with_prefix entry_label { foo_3 foo_4 } { > - foreach_with_prefix dwarf_version { 4 5 } { > +foreach_with_prefix entry_label { foo_2 } { > + foreach_with_prefix dwarf_version { 4 } { > run_test $entry_label $dwarf_version > } > } >