From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YdY8C2IMQWfLfDsAWB0awg (envelope-from ) for ; Fri, 22 Nov 2024 17:57:38 -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=nl43dw33; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 104611E25F; Fri, 22 Nov 2024 17:57:38 -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 C83DA1E1CC for ; Fri, 22 Nov 2024 17:57:36 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3364C385842A for ; Fri, 22 Nov 2024 22:57:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3364C385842A 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=nl43dw33 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05olkn20829.outbound.protection.outlook.com [IPv6:2a01:111:f403:2e12::829]) by sourceware.org (Postfix) with ESMTPS id E87823858D20 for ; Fri, 22 Nov 2024 22:56:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E87823858D20 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 E87823858D20 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2a01:111:f403:2e12::829 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1732316218; cv=pass; b=iE45OLoTlIpTvvCXHOzu78GOE/AWYUgILgTaI8V3nR4IPbv1D+kTU1lAngAZvTAGoOiGWxC4w4FomnWiVI2iPpeAB4qpvyIPvwuUmGpzUJaXlvp4xtnAWyRL8oujqF++nOYYh1jcLI0g/pCVhvaMG1Y8VqT55TLmjgyYNAoev5c= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1732316218; c=relaxed/simple; bh=E+nv/C/k44dFIN/CixmJeKeome5a4OqZue56o5ZJO+I=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=iwFx3zGCtzqzmCzk+vACrBPBOl/uWSkrVflhV/Sjb3VtlOfaKJVLlInTVdr4VGEL44S9RlppLvATAZDYI8IM6xKHe5+Qgc8u8z4ZKeYk4lc9zA0JBAPe7wC51mh0/aW6kSlMbDDilkGVNkSyIK+qvQ5ayDzEodsNAbThiosXGxE= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E87823858D20 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ADyuOYKid6Lx/VVnZtc3nzR7wBu0Dswn9juNq6IwNTmo3mE3RZY3fozZFavgLWVbHCVRyGNYRbLvQePIYCgj25dSZjvJZFIE4Hf8LEWFvWm9+Aj/CuucLwz9nhosSFIEe1C7p7QyC6a9OGHrWV/sJtFP3Sp86C1glBy+LnEEj5uyK5w4eDCPRkR3YJ+Gc6paQUDpSLqSZft05i/zljQHMbkfhl6yBRqcmRVk4O7J2T/4eb71GEb9wIfFDsvR5CPeHgESgxcUHEXpW+Tlp5Aha3JPgTGuicfMj+ektL+6XNfNsaB4y9SsdRVGrMZY6ixrW/Spfr/Iuy2Yv+9BKCk8fQ== 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=fHgX3kl76EbQKtgL5ayFf2eHOuadJL8a13e4/wS4SqQ=; b=trqskljj/Tcy3saClLzcFVckVjfuy1b7WNMxOx5NrR6WMBWM/K3p2d7Psy6r8wp9jRn/W88Y/CU4AoOMxid1HrhtT9ChAJapcuTWBaytgfA40twEO0b3jQ+ZMugyFZKvJ7TeoWTMlZjdYdLJZkQwgXbRDU2sNhiRxbvsMur8m0GhJCo+JC2QoilLUC+ds8Ir+t51Bo8EHuBeupMstZZXzScFtVwNs3xB1bApyaLPJY5qTCkFD5KjyNx6pkkthCzYvTeTpxFK+0RxLd6zhvSf86YztZnNi8Cw/RtQcvgnHwzIDl4WXjYk5y1t0Kz0TwhjBPDzaynC43f7dDsXz3YaZA== 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=fHgX3kl76EbQKtgL5ayFf2eHOuadJL8a13e4/wS4SqQ=; b=nl43dw33Wa32AThZ+9eCzJUyOeQoCuv8wGfyZXFxDoffPBTLyjw/WTKJ2ems0bmft4pWsJPtTQAlLWKZMRUaBHIELvN18YkXOl8orovsj63hY+y8C835SsJxRfwMt7UNVXNnZIqzlCv3mGzgCfFMdiZyXqt+K4Q3nevRihim0O3x/UL6zUndZJZt1+aHVy1Fm1OYV4VI8qgKaDaiB/wO1IVqz/Uedh8VplPTKue/0mCk+f0HI/GEH3x3vz/Y/5vtC9X5bTPPc5PxhR+G3Zb7Yypad5tCatCqSpqS874TN/6T2Ar+ADyEe/V75dNuVGUUR84wmVdDQNJ2fZvVrv5ekQ== Received: from DU2PR08MB10263.eurprd08.prod.outlook.com (2603:10a6:10:491::6) by PAVPR08MB8991.eurprd08.prod.outlook.com (2603:10a6:102:32f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8158.22; Fri, 22 Nov 2024 22:56:53 +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.8158.023; Fri, 22 Nov 2024 22:56:52 +0000 Message-ID: Date: Fri, 22 Nov 2024 23:57:55 +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> Content-Language: en-US From: Bernd Edlinger In-Reply-To: <87y11bw6p3.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR3P281CA0202.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a5::6) To DU2PR08MB10263.eurprd08.prod.outlook.com (2603:10a6:10:491::6) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR08MB10263:EE_|PAVPR08MB8991:EE_ X-MS-Office365-Filtering-Correlation-Id: a81aea92-7b1d-4238-a543-08dd0b48f449 X-Microsoft-Antispam: BCL:0; ARA:14566002|7092599003|8060799006|15080799006|6090799003|461199028|5072599009|19110799003|56899033|1602099012|10035399004|3412199025|4302099013|440099028; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Ni9kSCt0bjBxbTRLTmxhV0pyMEhsTk1IT2d2dk54VTU4dG43R1p3NHAxcXVM?= =?utf-8?B?MmdaL0Urb1dLaFVvOUxpc1pwOXI5QXNIVXdZaHJubWgxZ2s3ZWpyRkttR1ZK?= =?utf-8?B?NlduZkltc3BRVVRtbVZEUFhEakM2emd5WW5EMk9ndjMzUVBnMElJZGlKWWp6?= =?utf-8?B?bkN0UnQzVGtITFZXTWRHTURCSWh1VW1QQUdRcTRFL2loSEg0c3dHeDlYZjA0?= =?utf-8?B?NnpaSEw1NGFGVGlJQ3lWTTZhV0ZlQWVzMjFjTFZHd2lBZXdVUkJ0KzIvMTRp?= =?utf-8?B?RlMrZVlGVDBnK0dNZ29yK2pjdUxaQit3aWhoK2tOMUVPQjgza1N5SUNMN2Uw?= =?utf-8?B?TXhBaWNLbUVZR2VuTitDblRxQUtPbFRRZXRnb0kveWE3Z05JTkd3cE5sa3Zz?= =?utf-8?B?QzJSSUk4cWFvdzdPRTdrMmprRlZubS9aZ0ZyOUoyOWtWNHVmVUwzSURxajRB?= =?utf-8?B?VFpSNGZQbzk2ZXpkb3hOZVYwSGpaaFpUYUhXQjg4V2c3TkNORUtPY1ZEbWEy?= =?utf-8?B?NUJqMldTVE1mUHZ1dVVpaURmbHlZU3VFK2N3RUhQc3Q0S0ppZTZEejZOenBo?= =?utf-8?B?bkFHUkNpbmlucmlUTnk3L1luTFUxcEhZWmNsM3ErcmtYWktDcXZQaUFYSEpM?= =?utf-8?B?N2pROVRGb2Q0RUhvaXozbWVVbXJzTWNTNmJ2RytRclhRMmhWWE1HTUt3RlF6?= =?utf-8?B?dXk2ZUNxNzZmem5NaEE0ZEkvT0Qydmo1QUsvTklYS1ZMdEdCTjUzUE9VTzNO?= =?utf-8?B?cXV2THcxa0thdXErcTFSMk5RNzVaaUw4Y0ZRanFYYzVFU28vMFE2dk5IWUJv?= =?utf-8?B?UjB1MllXc2FDZEJzTG1vVkFuTFdoSEc1RGtVUFlEeTdwSlpDNndSWDJyNW5B?= =?utf-8?B?N0RPcGlpRTRXYXdSYkVVU2l0RXluOTI3K2hCUVFIU0hDdFJNczZ0L283YnQ4?= =?utf-8?B?Z0pBb2dFTVFzcmJuSllaTGNmdU9jWHVGN1poQnZQQmJ2M29ZNjlBSy9OYWlq?= =?utf-8?B?VC94YzN4WW9zWGtxUUx1d08vWlcyREVGL0VlVDlPeFhVUFkrb2xHRmlUM1RK?= =?utf-8?B?aitiVHA5ckNXZHptaCtjUHlNUzU4dU42bmFTT1FoVkZaREtOb0l3YVJia0I2?= =?utf-8?B?aHJuTzFObXpaUDdPUi92YWVSVk1KalBZdDhQUDhNamM1Q2ptTFpaN3dGNE5t?= =?utf-8?B?WGl3bUs2aTUzaDY2Q2N0Vkd3bUJmRUVvMXZMR3hxQmFndFNoYlBEaUpJZmYr?= =?utf-8?B?ZTZjbWdvYVBlK3Fqd3V4MlF5bG9WaTcrNnhCcHVVa1lHNzAvWUl2NUpUZzM5?= =?utf-8?B?cHU1M3hrM2xLVTR3a05RUlJ2cy85NnVPenNNQkY3UnMxWFR3MEdTOGloTWdP?= =?utf-8?B?d2R0QTN0L3VPOEF1MU1BdkdYTXp5MEhoRmNUMmhtZlJ4d1NzaU9CSXArRXNN?= =?utf-8?B?N2UzeUoxQStDZGIyR2RJaCtYNnljTTdrN3czMTR6OUg5b1lyVFhoRERsNTlv?= =?utf-8?B?dlpKVVFkdkJoQVBENU9zQi85NkFMUUhWMTd0dU9EU0p4dDRRQVJVU3QySjZT?= =?utf-8?Q?xG17A2Z9v9LT+C+LYQ5ljAaZ7TaRKZGjx1xzYDIGB8WrE9?= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V2xnQyt5cmtsaWNiZG9yWGZLb3pSM0NpNXpTM3dpSWNqdGZyejFSUE9zL2VM?= =?utf-8?B?RFBxRjl2bzNYQTVwd1RGLzU4Q3NOWFhNLzd2NS9vTSs0MmVOT0lSSTQ5eDEy?= =?utf-8?B?TjB3SkhzQis3a29vMHJYdHBkc01WNkc0b2t5T2hXamxic2VNaUhXT0NtT3Yw?= =?utf-8?B?YTFDMWx5MzM2bHVLQTRLdDBnVmZSNXVaY2Z4S0wwWTVuRG9VY3NZQisvZHVD?= =?utf-8?B?VHZzejFoY3I5NnRDOUxPSzF3Y0ZaUG1JaytWRlVyajdOem5INkpEdHZ6ZHJz?= =?utf-8?B?eC9KNGlqZkF0ejNXMkVOcGJaU0t4TVZRSG9ZdVY5aWNEWnJsaFVhQStSSW5O?= =?utf-8?B?bWxZdkJxQUVmMVB4ckVQWTduNzlyeHl5Q3FPbkVUWlBmMXpiNGJXeTg3aUVT?= =?utf-8?B?N3hldXNWMTB0MnlvOWtIUEprbVh4TjA0dnpRMlZ3RDk0WmhFQzhQbGdyN09U?= =?utf-8?B?VWlJamQwY2JaM2xUTVpSeTNabEpWYXJGWUpwdGFTaTc2dG5LS05ZY1FsZVVn?= =?utf-8?B?aW1YOUxHS0R5NEF0c1kxZTRPdnhVRlM1S2dkWU5obFd0ak03ckE2VWNGNWZy?= =?utf-8?B?Ukx3NC9NRGl0TE16TzlZSmNORmNoMVRBVjE5azNaMkpFSkFqT09GSHdSSWk2?= =?utf-8?B?YXhQRlVFWVkwZXlCeklnQ3FTdnkyTXRrLzF3dC9VZ1B0T3kxNmN0MzQrUndN?= =?utf-8?B?M0dZVnU0Nk1tMi9DNjhjdVF6djkzcDR2aFp4TTBjanNQbXJ4K3dubHZPcHpS?= =?utf-8?B?ZE16NFRHdEh4N3BXVUxIMUJJNXQxVTZDSUdkWGNVZFJkUnRLUER4Rm9RSE9r?= =?utf-8?B?eUxnc1Jqb1dYalAyZUdzVWtaVjE2SmJsZ3J6VGZKTEpvbWgvOWM0dkVES21D?= =?utf-8?B?N2VnanB4bjlUTWtka2lhbjFBTkJOTDVQRDROQzJTYVA1akdiMS84TDFoUkJ5?= =?utf-8?B?ZGI1MEJvdW1Pd2xRNjRoUkNtUnlqZ0M5WHFLTE9uRHpmalNLVEorU3EwdUNr?= =?utf-8?B?dThoOVd6UXFNdVpYSE9zL293ZjJscTNFeFVlYWVBNXRzcTRLdzBVZDVhZDda?= =?utf-8?B?YWVSeUxYaTM5c2JJVHFUajQ1SjAybko2d0pWYjBlUDhURjR6SEY0emF3dnNi?= =?utf-8?B?ZmdVSUpBOCs5Qm9WdGRJRW13OWZURWxGcmdLd3hzbmw5K0d5TFFoQk16ZzRU?= =?utf-8?B?bjJyNnhrcnRYSmM3VnlvVlpPam9rRzROZFVQSTk4WWVLZGR4Y2dQZE5vSzNi?= =?utf-8?B?dkZzQXE2ZE5BRG9ENURkTEVXekxzMktIc3pwNGpxZFV5dUl1K05sYi9SZDJv?= =?utf-8?B?L1lpUmp1K1hkZjdpc3pkS3RvSGRSN3VNTTJIK1hreVVkcFdoaFhiSHNxRGU4?= =?utf-8?B?blE2L1QrWlBua1BTNDhyNEJjcmZtY2dDaWdabjdPeVpZUFZSYTdGd0NUbFYz?= =?utf-8?B?aGdsTVJpeGNtUHowdWk5NEZjaDlzVGRHSEFUdTFkQjV5ZVZKNHhZZ1NGWVgy?= =?utf-8?B?b0d1RkU2YTNxZVgxWEgvRGprV3VYL01qc0tSVERzOVQ4WUk2eisvYXZHOTdk?= =?utf-8?B?cnl4YkRaMjBkekY4Q2Y4K0tPSzRaK3RrNm8rVDc4WHlNL08rdVppY2MzalZu?= =?utf-8?B?dzFEdVRpS29BaTJKbktBZXdZNmpaT2hZeEFjeTQyUHFQMVJQQmFGcGhVMkEv?= =?utf-8?B?eS9EdkpuWDBjQlF6NHdybzNjeU41NDBmaTY4Z0NVaktIb2t4Q25OM2c2dlFh?= =?utf-8?Q?yW180D4lQMZAeEb6S9sy7jGubm0DfqjJqfarcfY?= X-OriginatorOrg: sct-15-20-7719-20-msonline-outlook-de33f.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: a81aea92-7b1d-4238-a543-08dd0b48f449 X-MS-Exchange-CrossTenant-AuthSource: DU2PR08MB10263.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2024 22:56:52.4284 (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: PAVPR08MB8991 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/22/24 17:53, Andrew Burgess wrote: > Bernd Edlinger writes: > >> Hmm, sorry, but I think this goes in the wrong direction. >> >> On 11/20/24 16:01, Andrew Burgess wrote: >>> The test gdb.cp/step-and-next-inline.exp creates a test binary called >>> step-and-next-inline-no-header. This test includes a function >>> `tree_check` which is inlined 3 times. >>> >>> When testing with some older versions of gcc (I've tried 8.4.0, 9.3.1) >>> we see the following DWARF representing one of the inline instances of >>> tree_check: >>> >>> <2><8d9>: Abbrev Number: 38 (DW_TAG_inlined_subroutine) >>> <8da> DW_AT_abstract_origin: <0x9ee> >>> <8de> DW_AT_entry_pc : 0x401165 >>> <8e6> DW_AT_GNU_entry_view: 0 >>> <8e7> DW_AT_ranges : 0x30 >>> <8eb> DW_AT_call_file : 1 >>> <8ec> DW_AT_call_line : 52 >>> <8ed> DW_AT_call_column : 10 >>> <8ee> DW_AT_sibling : <0x92d> >>> >>> ... >>> >>> <1><9ee>: Abbrev Number: 46 (DW_TAG_subprogram) >>> <9ef> DW_AT_external : 1 >>> <9ef> DW_AT_name : (indirect string, offset: 0xe8): tree_check >>> <9f3> DW_AT_decl_file : 1 >>> <9f4> DW_AT_decl_line : 38 >>> <9f5> DW_AT_decl_column : 1 >>> <9f6> DW_AT_linkage_name: (indirect string, offset: 0x2f2): _Z10tree_checkP4treei >>> <9fa> DW_AT_type : <0x9e8> >>> <9fe> DW_AT_inline : 3 (declared as inline and inlined) >>> <9ff> DW_AT_sibling : <0xa22> >>> >>> ... >>> >>> Contents of the .debug_ranges section: >>> >>> Offset Begin End >>> ... >>> 00000030 0000000000401165 0000000000401165 (start == end) >>> 00000030 0000000000401169 0000000000401173 >>> 00000030 0000000000401040 0000000000401045 >>> 00000030 >>> ... >>> >>> Notice that one of the sub-ranges of tree-check is empty, this is the >>> line marked 'start == end'. As the end address is the first address >>> after the range, this range cover absolutely no code. >>> >>> But notice too that the DW_AT_entry_pc for the inline instance points >>> at this empty range. >>> >>> Further, notice that despite the ordering of the sub-ranges, the empty >>> range is actually in the middle of the region defined by the lowest >>> address to the highest address. The ordering is not a problem, the >>> DWARF spec doesn't require that ranges be in any particular order. >>> >>> However, this empty range is causing issues with GDB newly acquire >>> DW_AT_entry_pc support. >>> >>> GDB already rejects, and has done for a long time, empty sub-ranges, >>> after all, the DWARF spec is clear that such a range covers no code. >>> >>> The recent DW_AT_entry_pc patch also had GDB reject an entry-pc which >>> was outside of the low/high bounds of a block. >>> >>> But in this case, the entry-pc value is within the bounds of a block, >>> it's just not within any useful sub-range. As a consequence, GDB is >>> storing the entry-pc value, and making use of it, but when GDB stops, >>> and tries to work out which block the inferior is in, it fails to spot >>> that the inferior is within tree_check, and instead reports the >>> function into which tree_check was inlined. >>> >>> I've tested with newer versions of gcc (12.2.0 and 14.2.0) and with >>> these versions gcc is still generating the empty sub-range, but now >>> this empty sub-range is no longer the entry point. Here's the >>> corresponding ranges table from gcc 14.2.0: >>> >> >> Yeah, maybe not in this test case, but that is not true in general, >> a quick check with gcc-15 shows that there still a number of such >> empty range table entries in the gdb executable itself. >> >> Note that ignoring these entry_pc values is completely wrong, >> and my patch series handles exactly these empty subranges, by not >> ignoring them in the dwarf reader, and the debug experience is >> completely normal when this happens. >> >> Furthermore, I think that having a break point at these PC values has >> some benefit, because it is the earliest point in time, when all >> the input parameter values of the inline function are available, >> and can be inspected by gdb. > > I hear and understand your frustration. I'm absolutely not ignoring the > work you've done. But I see this as a journey of small steps to get > where you want to be. > > I agree with you 100% that dealing better with the empty sub-ranges is > the right way to go, and indeed, I have just finished pulling the empty > sub-range work from your series, and I plan to post those patches > hopefully over the weekend, I'm just running final tests now. > > But, this patch does more than just deal with the case of entry-pc > pointing at the empty sub-range. I believe that having a sanity check > that the entry-pc is within any sub-range is the right thing for GDB to > do, regardless of what we ultimately end up doing with empty ranges. > > I'm hoping I can convince you that fixing this first is not going to > prevent us merging your empty sub-range handling code next. > >> I think now it is time to consider merging the rest of my >> patch. > > My top priority between now and year end is to merge either your > patches, or equivalent functionality, into GDB. But, as you can tell > from what I've posted, I think your series covers a lot of fixes which > should be broken into separate commits. > > I think the work you have done is absolutely amazing, and makes huge > improvements to GDB's handling of optimised code, I just don't want to > rush things, but I'm certain we will get there. > > Thanks, > Andrew > 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. Thanks Bernd.