From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KP3WBu4YvGkDYDAAWB0awg (envelope-from ) for ; Thu, 19 Mar 2026 11:40:30 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=VUM66J8u; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 09E331E08C; Thu, 19 Mar 2026 11:40:30 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED,WEIRD_PORT autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (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 F18F91E08C for ; Thu, 19 Mar 2026 11:40:28 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 639D24BC898B for ; Thu, 19 Mar 2026 15:40:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 639D24BC898B Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=VUM66J8u Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id E5C9D4BBCDD1 for ; Thu, 19 Mar 2026 15:39:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E5C9D4BBCDD1 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E5C9D4BBCDD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773934800; cv=none; b=GY7TrCReGgjAsboi5Pw73biWgtuNR/T/uqJ8X9p9nTszuTT/iWmuCr37LXqpp4MgVgd1kw0P2mV/9hrNaGaZO/RNMR1+J7wwzYCW0r7oOUnSSNJ74MO44+NI2XlCpXTUoFQxdQGuUuFJTfg92BxcAn1zky8kfLiRBM3BUsufMw4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773934800; c=relaxed/simple; bh=qIOEjbtLut3naZBQx8kBC62ytWeBpi6gMHyLNSL+LtE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=mhOw9Gtwyz89Pq37+kdiG7ukSk7+twfR1A/ig9/3HEIG8LDKuowIaSAXigCRhB0JSJ2tGKg4gGLdG01mqTYzuQd3lPV3V5I9pa6L37tzF4dlfpnCb+I9NfOaPuE5hc7V9RAgMCeWVFaL/CZdwluAPIxHKicQnxKcGhC1AeY6RN4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E5C9D4BBCDD1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773934799; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Wt9wp515NvayrCT9Hqvx8xOpsD0n0PgmcqOH+L1R/dY=; b=VUM66J8uujinXmLCSBIsEtyLpv7F0i8/ewleKBWS5plH5bBEonsdfuah6IIKFHwl/Nnod1 opcX05iYm4wxBa/effatpJLdOgtu/sJrwJ9QutglIsuFDWIHcak90OkRoX4wG95gdyTciU WUxdTh/0FXLhmh/d05DkZSIfIbLPh6g= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-691-7jsm-OxmMI6d76Rs2KL4qQ-1; Thu, 19 Mar 2026 11:39:57 -0400 X-MC-Unique: 7jsm-OxmMI6d76Rs2KL4qQ-1 X-Mimecast-MFC-AGG-ID: 7jsm-OxmMI6d76Rs2KL4qQ_1773934797 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-439c54e0f6aso688293f8f.0 for ; Thu, 19 Mar 2026 08:39:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773934796; x=1774539596; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Wt9wp515NvayrCT9Hqvx8xOpsD0n0PgmcqOH+L1R/dY=; b=d4uroEIo/Wo1RSwKmQgfeNy8hnuR5vewIndUqWIpDi/lVKuXc1UzpEIfHBZ5O8qXSn Zwe+X5WM4xhL2bdj+BeaevJiehZ1Vt9PYLzVFyK7l8yD1hgM+th2efvZ6Dxs2KRuUAQt ybC3gBTx5j0ZxFAAMaxxolqYyJINoP6D5N3h4DDg35cSfkvbEOn9IRKBebCE4SKk5mgm D0JKMuOrqHdWvidwj2i+ylQ3GFaXHpIp27m59MPBZ8wB4NQYUVDhtKEpBrxQKrZzBcCy bTqKBjoQgxhGDhtFqMD6/H1aYXdPJUKF2gIx3Q+svXY6fBF1x7FciWHyw/Y+XleKa5Kk rUgQ== X-Forwarded-Encrypted: i=1; AJvYcCWQt06668jchbtknq1v8zhykobaaPU+ETt+q30A9ctTsl5xnD8Cz3Ur7jCUiwGObHggpgeRtF+uUDhFgA==@sourceware.org X-Gm-Message-State: AOJu0YwOYBrAopK8sgXRKlxMCL2rOzBuBJpljR3+RaK6bDL3OOFWARrU nPf9ntJTsGlMRSQCUra1VayzPvshZhaC6DbdzMkb25Om/LVaLL+kWmKfRkg8WOuFhRWcurS1U2L S7UYlNWXHtfzQl47JEBtBrZCKjXHwW4Mr7t2gNwIQthc77085WB4+EukPY7KkUFRcE3zx5cU= X-Gm-Gg: ATEYQzwYo1NKYyb8sHR/w7edEwwZvoqUT/O/d/7GG+03VZEFZfdw210VW7b/ORlwVa4 557ZQu43jiH3jaRhM8V7hV63WleqVy1xTcXDQTzocpwXPfBiecToqvNmHTB2PFU+PUHxDKdDZxn t4E/uNnrWEN2G3GfaeyA1cedAP67vIQ0+3uDx8Wauv1wM28W9dXTfLqA7CeSz0dQlCyAYSgiBvv nuXwukv9lX6jrMREeJUwSypo6upl9PwFoEJPu9jA+MXGtR9K+RR45LpFNRAFkA0iBE7IEyYP1PF EcPNKLCpXC0K4QSUpqk9+QBVHH3WvHa7bv/k5LJCNuTTxyuggJueCNV1FbNNcu2X0kxW0SDnPy5 CrkOa5JelJj02wriC X-Received: by 2002:a05:6000:420e:b0:43b:42db:6b77 with SMTP id ffacd0b85a97d-43b576a6dd9mr7785590f8f.0.1773934796090; Thu, 19 Mar 2026 08:39:56 -0700 (PDT) X-Received: by 2002:a05:6000:420e:b0:43b:42db:6b77 with SMTP id ffacd0b85a97d-43b576a6dd9mr7785519f8f.0.1773934795455; Thu, 19 Mar 2026 08:39:55 -0700 (PDT) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b51805291sm16979477f8f.0.2026.03.19.08.39.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Mar 2026 08:39:54 -0700 (PDT) From: Andrew Burgess To: Tom de Vries , gdb-patches@sourceware.org Subject: Re: [PATCH 3/3] [gdb/symtab] Tweak fix-up of truncated inline function block ranges In-Reply-To: <20260302114849.1797017-4-tdevries@suse.de> References: <20260302114849.1797017-1-tdevries@suse.de> <20260302114849.1797017-4-tdevries@suse.de> Date: Thu, 19 Mar 2026 15:39:53 +0000 Message-ID: <87bjgj6d6e.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 6FeBKEjwAJIacEAZVW5ZlT7K1T5Ui39B1zc6ftJg-Oo_1773934797 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Hi Tom, Thanks for looking at this. Tom de Vries writes: > Consider test-case gdb.cp/step-and-next-inline.exp on ppc64le-linux. > > The corresponding source file step-and-next-inline.cc contains functions > tree_check and get_alias_set: > ... > 35 #define TREE_TYPE(NODE) (*tree_check (NODE, 0)) > 36 > 37 inline tree * > 38 tree_check (tree *t, int i) > 39 { > 40 if (t->x != i) > 41 abort(); > 42 tree *x = t; > 43 return x; > 44 } > ... > 48 int __attribute__((noinline, noclone)) > 49 get_alias_set (tree *t) > 50 { > 51 if (t != NULL > 52 && TREE_TYPE (t).z != 1 > 53 && TREE_TYPE (t).z != 2 > 54 && TREE_TYPE (t).z != 3) > 55 return 0; > 56 return 1; > 57 } > ... > as well as a trivial function main calling get_alias_set. > > Say we step into the first call to tree_check, and then step to the return > at line 43: > ... > (gdb) s > tree_check (i=0, t=0x10020030 ) at step-and-next-inline.cc:40 > 40 if (t->x != i) > (gdb) s > 43 return x; > (gdb) > ... > > At that point, we have pc 0x1000071c: > ... > (gdb) p $pc > $1 = (void (*)(void)) 0x1000071c > (gdb) > ... > and the backtrace looks like this: > ... > (gdb) bt > #0 tree_check (i=, t=) at > step-and-next-inline.cc:43 > #1 get_alias_set (t=t@entry=0x10020030 ) at step-and-next-inline.cc:52 > #2 0x0000000010000560 in main () at step-and-next-inline.cc:64 > (gdb) > ... > which shows all 3 functions. > > This seems trivial, but it's not. > > All three calls to tree_check are inlined, and the first call is represented > by: > ... > <2><877>: Abbrev Number: 40 (DW_TAG_inlined_subroutine) > <878> DW_AT_abstract_origin: <0x967> > <87c> DW_AT_entry_pc : 0x10000710 > <884> DW_AT_GNU_entry_view: 0 > <885> DW_AT_ranges : 0xc > <88a> DW_AT_call_line : 52 > ... > with DW_AT_ranges referring to: > ... > Contents of the .debug_rnglists section: > > Offset Begin End > 0000000c 0000000010000710 (base address) > 00000015 0000000010000710 000000001000071c > 00000018 000000001000077c 000000001000077c (start == end) > 0000001b 0000000010000788 0000000010000790 > 0000001f > ... > > The range at offset 0x15 is [0x10000710, 0x1000071c), so address 0x1000071c > does not fall in the range, and consequently the debug info does not consider > 0x1000071c part of the inlined tree_check. > > However, since commit 8efed40efd6 ("gdb: fix-up truncated inline function > block ranges"), gdb contains a fix in lnp_state_machine::record_line: > ... > if (m_address != m_last_address > && m_stmt_at_address > && m_cu->producer_is_gcc () > && (m_flags & LEF_IS_STMT) == 0) > dwarf_find_and_extend_inline_block_range (m_cu, m_last_address, > m_address, m_line); > ... > that looks at the corresponding line number information: > ... > File name Line number Starting address View Stmt > step-and-next-inline.cc 42 0x1000071c x > step-and-next-inline.cc 43 0x1000071c 1 x > step-and-next-inline.cc 43 0x1000071c 2 > step-and-next-inline.cc 52 0x1000071c 3 > step-and-next-inline.cc 52 0x10000720 > ... > and extends the range of the inlined tree_check to include > [0x1000071c, 0x10000720). > > [ Please read the commit message of aforementioned commit to understand why > the fix is correct. ] I think it's worth discussing the idea behind the aforementioned commit at this point because it is the reason behind my later thoughts. What that commit does is modify the debug information. It has GDB trying to decide that it, GDB, knows better than the compiler, what the debug information should look like. This is always going to come with a degree of risk. To restrictive and the "fix" will not trigger often enough to provide real benefits to the user. To loose and the "fix" ends up triggering in cases where it shouldn't, making the debug experience worse. The pattern I observed, and sort-of tried to match (more on this below), is as follows: 1. A series of line entries at the end address for (one of) an inline function's ranges. 2. The first of these line entries is a STMT, while the subsequent entries are non-STMT. 3. The last of these line entries is a non-STMT and is associated with the calling line of the inline function. 4. The next line entry is a non-STMT, and is also associated with the calling line of the function. Now I said above that I 'sort-of' tried to match this pattern. Honestly, I don't think I did a great job, only some of these characteristics are actually matched. Lets go through and see which characteristics are, or are not actually checked for: 1. This is checked inside dwarf_find_and_extend_inline_block_range where we check if original_address matches the end address of an inline function range. 2. For this we check m_stmt_at_address, but this isn't exactly correct. If _any_ of the line entries at the previous address are marked as STMT then this will be true (and count at a match), this is probably OK in most cases except for the next point.... 3. We don't really check this at all; as you point out we check the current line, not the previous one, and m_stmt_at_address will be true if the previous entry is a STMT, which I think would be bad. 4. We do check the non-STMT part, and we check the line number part. So I was a little sloppy with the STMT checking, and should have taken care to add both line number checks. I mention this because at this point your commit message seem (IMHO) to focus on the is-stmt logic even though that's not really the part you end up fixing. > > Let's look in more detail at how the call to > dwarf_find_and_extend_inline_block_range is activated for the fix. It's > activated for the last entry (52/0x10000720), with: > - m_last_address == 0x1000071c, > - m_address == 0x10000720, and > - m_line == 52 (matching the DW_AT_call_line). > > It's easy to see that for the last entry, (m_flags & LEF_IS_STMT) == 0 holds, > because it doesn't have an x in the "Stmt" column. > > I found it less obvious that m_stmt_at_address also holds. > > [ The documentation clarifies that this is related to m_last_address: > .... > /* Set to true when a previous line at the same address (using > m_last_address) had LEF_IS_STMT set in m_flags. This is reset to false > when a line entry at a new address (m_address different to > m_last_address) is processed. */ > bool m_stmt_at_address = false; > ... > > To get maximum clarity, I checked the value for each entry: > ... > address m_stmt_at_address > --------------------------------- > before false > 42/0x1000071c false->true > 43/0x1000071c/1 true > 43/0x1000071c/2 true > 52/0x1000071c/3 true > 52/0x10000720 true->false > ... > > Again it's easy to relate the transitions for particular entries to the "Stmt" > column. > > The tricky bit is that the transition takes place at the end of > lnp_state_machine::record_line, so while processing entry 52/0x10000720, we > sample m_stmt_at_address while it's still true. ] > > Likewise, the fix works for the second inlined call. > > But not for the third. The debug info has the same problem, but the fix is > not applied. > > The corresponding line info looks slightly different: > ... > File name Line number Starting address View Stmt > step-and-next-inline.cc 42 0x1000074c x > step-and-next-inline.cc 43 0x1000074c 1 x > step-and-next-inline.cc 43 0x1000074c 2 > step-and-next-inline.cc 54 0x1000074c 3 > step-and-next-inline.cc 55 0x10000750 > ... > > In this case, dwarf_find_and_extend_inline_block_range gets called with: > - m_last_address == 0x1000074c, > - m_address == 0x10000750, and > - m_line == 55, > but since line 55 doesn't match DW_AT_call_line 54: Your discussion of the is-stmt handling / tracking is all correct, but the cause of the problem is captured in these last 5 lines, the next line is not associated with the function's calling line, but with the next source line. > ... > <2><918>: Abbrev Number: 44 (DW_TAG_inlined_subroutine) > <919> DW_AT_abstract_origin: <0x967> > <91d> DW_AT_entry_pc : 0x10000740 > <925> DW_AT_GNU_entry_view: 0 > <926> DW_AT_low_pc : 0x10000740 > <92e> DW_AT_high_pc : 0xc > <937> DW_AT_call_line : 54 > ... > the fix is not applied. > > I'm proposing the following simple tweak, to handle the third inlined call as > well: instead of using m_line, use m_last_line. If I'd done my job better when I wrote the original commit then we would have been checking BOTH lines already, and requiring that they both match the calling line; that after all was the original pattern I spotted. So in my mind the question is, if I had done a better job of matching the pattern, would it be OK to loosen that matching? I'm a little conflicted on this, but I think it's probably worth the risk. > > Tested on x86_64-linux and ppc64le-linux. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33930 > --- > gdb/dwarf2/line-program.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/gdb/dwarf2/line-program.c b/gdb/dwarf2/line-program.c > index b9d93bb7b0e..5aa97ea3714 100644 > --- a/gdb/dwarf2/line-program.c > +++ b/gdb/dwarf2/line-program.c > @@ -445,12 +445,25 @@ lnp_state_machine::record_line (bool end_sequence) > (end_sequence ? "\t(end sequence)" : "")); > } > > + /* Activate dwarf_find_and_extend_inline_block_range for line number info: > + > + Line number Starting address View Stmt > + 42 0x1000074c x > + 43 0x1000074c 1 x > + 43 0x1000074c 2 > + 54 0x1000074c 3 > + 55 0x10000750 > + > + at entry 55/0x10000750 with: > + - m_last_address == 0x1000074c > + - m_address == 0x10000750 > + - m_last_line == 54. */ > if (m_address != m_last_address > && m_stmt_at_address > && m_cu->producer_is_gcc () > && (m_flags & LEF_IS_STMT) == 0) I wonder if should extend the condition with `&& m_line >= m_last_line`? Under my original scheme I _should_ have been checking `& m_line == m_last_line` and your change is to relax that constraint to `>=`. > dwarf_find_and_extend_inline_block_range (m_cu, m_last_address, > - m_address, m_line); > + m_address, m_last_line); > This patch will need rebasing onto your frame printing patch once that's merged, and I guess you'll be enabling the additional tests that are in that patch and currently disabled so that this commit gets some tests. But I think this change is the right way to go, we just need to be mindful that as we relax the match criteria we run the risk of having GDB change the debug info in non-helpful ways. Thanks, Andrew