[PATCH v2 0/5] [gdb/symtab] Tweak fix-up of truncated inline function block ranges

[PATCH v2 0/5] [gdb/symtab] Tweak fix-up of truncated inline function block ranges

[Tom de Vries]

This patch series fixes PR33930, a FAIL in test-case
gdb.cp/step-and-next-inline.exp on ppc64le-linux.

The first patch is a simple refactoring patch, renaming
lnp_state_machine::m_last_line (tracking the last recorded line) to the more
accurate m_last_recorded_line.

The second patch reintroduces lnp_state_machine::m_last_line, with semantics
matching the name (tracking all lines, not just recorded ones).

The third patch is another refactoring patch, simplifying the conditional
assignment of lnp_state_machine::m_last_address.

The fourth patch is yet another refactoring patch, adding
lnp_state_machine::m_stmt_at_last_address.

The fifth patch uses lnp_state_machine::m_last_line in the actual fix.

A v1 was submitted here [1].

Changes in v2:
- add a refactoring patch, simplifying the conditional assignment of
  lnp_state_machine::m_last_address
- add a refactoring patch, adding lnp_state_machine::m_stmt_at_last_address
- remove workaround in gdb.dwarf2/dw2-extend-inline-block.exp

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33930

[1] v1 https://sourceware.org/pipermail/gdb-patches/2026-March/225480.html

Tom de Vries (5):
  [gdb/symtab] Rename lnp_state_machine::m_last_line to
    m_last_recorded_line
  [gdb/symtab] Re-add lnp_state_machine::m_last_line
  [gdb/symtab] Simplify assignment in lnp_state_machine::record_line
  [gdb/symtab] Add lnp_state_machine::m_stmt_at_last_address
  [gdb/symtab] Tweak fix-up of truncated inline function block ranges

 gdb/dwarf2/line-program.c                     | 52 ++++++++++++-------
 .../gdb.dwarf2/dw2-extend-inline-block.exp    |  5 --
 2 files changed, 34 insertions(+), 23 deletions(-)


base-commit: 971b0152e92d381917bb089b3783959c5feb552e
-- 
2.51.0

[PATCH v2 1/5] [gdb/symtab] Rename lnp_state_machine::m_last_line to m_last_recorded_line

[Tom de Vries]

In class lnp_state_machine, we have member m_last_line:
...
  /* The last line number that was recorded, used to coalesce
     consecutive entries for the same line.  This can happen, for
     example, when discriminators are present.  PR 17276.  */
  unsigned int m_last_line = 0;
...
representing the last recorded line.

Let's make this situation more clear, and rename it to m_last_recorded_line.
---
 gdb/dwarf2/line-program.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gdb/dwarf2/line-program.c b/gdb/dwarf2/line-program.c
index b9da1b4799f..6020fe1fa55 100644
--- a/gdb/dwarf2/line-program.c
+++ b/gdb/dwarf2/line-program.c
@@ -196,7 +196,7 @@ class lnp_state_machine
   /* The last line number that was recorded, used to coalesce
      consecutive entries for the same line.  This can happen, for
      example, when discriminators are present.  PR 17276.  */
-  unsigned int m_last_line = 0;
+  unsigned int m_last_recorded_line = 0;
   bool m_line_has_non_zero_discriminator = false;
 };
 
@@ -301,7 +301,7 @@ lnp_state_machine::record_line_p ()
 {
   if (m_builder->get_current_subfile () != m_last_subfile)
     return true;
-  if (m_line != m_last_line)
+  if (m_line != m_last_recorded_line)
     return true;
   /* Same line for the same file that we've seen already.
      As a last check, for pr 17276, only record the line if the line
@@ -495,7 +495,7 @@ lnp_state_machine::record_line (bool end_sequence)
 	    {
 	      m_last_subfile = m_builder->get_current_subfile ();
 	      record_line_1 (m_line, lte_flags);
-	      m_last_line = m_line;
+	      m_last_recorded_line = m_line;
 	    }
 	}
     }
-- 
2.51.0

[PATCH v2 2/5] [gdb/symtab] Re-add lnp_state_machine::m_last_line

[Tom de Vries]

In class lnp_state_machine, we have member:
...
  /* The address of the last line entry.  */
   unrelocated_addr m_last_address;
...
representing the address of the last line entry.

Add a similar member for the line of the last line entry.
---
 gdb/dwarf2/line-program.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gdb/dwarf2/line-program.c b/gdb/dwarf2/line-program.c
index 6020fe1fa55..c6e28c01d67 100644
--- a/gdb/dwarf2/line-program.c
+++ b/gdb/dwarf2/line-program.c
@@ -181,8 +181,9 @@ class lnp_state_machine
   /* The last file a line number was recorded for.  */
   struct subfile *m_last_subfile = NULL;
 
-  /* The address of the last line entry.  */
+  /* The address and line of the last line entry.  */
   unrelocated_addr m_last_address;
+  unsigned int m_last_line = 0;
 
   /* 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
@@ -508,6 +509,8 @@ lnp_state_machine::record_line (bool end_sequence)
       m_last_address = m_address;
     }
   m_stmt_at_address |= (m_flags & LEF_IS_STMT) != 0;
+
+  m_last_line = m_line;
 }
 
 lnp_state_machine::lnp_state_machine (struct dwarf2_cu *cu, gdbarch *arch)
-- 
2.51.0

[PATCH v2 3/5] [gdb/symtab] Simplify assignment in lnp_state_machine::record_line

[Tom de Vries]

Function lnp_state_machine::record_line contains this conditional assignment:
...
  if (m_last_address != m_address)
    {
      ...
      m_last_address = m_address;
    }
...

While it's true that there's no need to update m_last_address if
m_last_address == m_address, this can be expressed much simpler using an
unconditional assignment:
...
  m_last_address = m_address;
...

Fix this by using an unconditional assignment, and moving it alongside a
similar assignment:
...
+  m_last_address = m_address;
   m_last_line = m_line;
...

Tested on x86_64-linux.
---
 gdb/dwarf2/line-program.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/gdb/dwarf2/line-program.c b/gdb/dwarf2/line-program.c
index c6e28c01d67..d821de14e76 100644
--- a/gdb/dwarf2/line-program.c
+++ b/gdb/dwarf2/line-program.c
@@ -504,12 +504,10 @@ lnp_state_machine::record_line (bool end_sequence)
   /* Track whether we have seen any IS_STMT true at m_address in case we
      have multiple line table entries all at m_address.  */
   if (m_last_address != m_address)
-    {
-      m_stmt_at_address = false;
-      m_last_address = m_address;
-    }
+    m_stmt_at_address = false;
   m_stmt_at_address |= (m_flags & LEF_IS_STMT) != 0;
 
+  m_last_address = m_address;
   m_last_line = m_line;
 }
 
-- 
2.51.0

[PATCH v2 4/5] [gdb/symtab] Add lnp_state_machine::m_stmt_at_last_address

[Tom de Vries]

Consider lnp_state_machine::stmt_at_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;
...
set at the end of lnp_state_machine::record_line:
...
  /* Track whether we have seen any IS_STMT true at m_address in case we
     have multiple line table entries all at m_address.  */
  if (m_last_address != m_address)
    m_stmt_at_address = false;
  m_stmt_at_address |= (m_flags & LEF_IS_STMT) != 0;
...

Now consider this line number information:
...
File name                    Line number    Starting address    View    Stmt
step-and-next-inline.cc               40          0x10000714
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
step-and-next-inline.cc               38          0x10000728               x
...

If we calculate the values of m_stmt_at_address:
...
entry            m_address   m_last_address  m_stmt  m_stmt_at_address
----------------------------------------------------------------------
40/0x10000714    0x10000714  -               0       0
42/0x1000071c    0x1000071c  0x10000714      1       0
43/0x1000071c/1  0x1000071c  0x1000071c      1       1
43/0x1000071c/2  0x1000071c  0x1000071c      0       1
52/0x1000071c/3  0x1000071c  0x1000071c      0       1
52/0x10000720    0x10000720  0x1000071c      0       1
38/0x10000728    0x10000728  0x10000720      1       0
...
we observe a skew of one entry between m_stmt and m_stmt_at_address.

Looking at entry 52/0x10000720, the value of m_stmt_at_address == 1 is in
contradiction with the documentation: A value of 1 implies that there is a
previous entry at the same address, and there isn't.

This was not a problem for the initial use, which only happened if
m_last_address == m_address:
...
      bool ignore_this_line
	= ((file_changed && !end_sequence && m_last_address == m_address
	    && ((m_flags & LEF_IS_STMT) == 0)
	    && m_stmt_at_address)
	   || (!end_sequence && m_line == 0));
...

But recent commit 8efed40efd6 ("gdb: fix-up truncated inline function block
ranges") introduced a use for the opposite case:
...
   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);
...

While that use is correct, using it in a context where the value contradicts
the documentation is problematic.

Fix this by moving the calculation of m_stmt_at_address to the start of
record_line, removing the skew, and creating a much easier to understand
concept:
...
entry            m_address   m_last_address  m_stmt  m_stmt_at_address
----------------------------------------------------------------------
40/0x10000714    0x10000714  -               0       0
42/0x1000071c    0x1000071c  0x10000714      1       1
43/0x1000071c/1  0x1000071c  0x1000071c      1       1
43/0x1000071c/2  0x1000071c  0x1000071c      0       1
52/0x1000071c/3  0x1000071c  0x1000071c      0       1
52/0x10000720    0x10000720  0x1000071c      0       0
38/0x10000728    0x10000728  0x10000720      1       1
...
and introducing an m_stmt_at_last_address (similar to m_last_address and
m_last_line in the sense that they represent the value of a state variable
when processing the previous entry).

Tested on x86_64-linux.
---
 gdb/dwarf2/line-program.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/gdb/dwarf2/line-program.c b/gdb/dwarf2/line-program.c
index d821de14e76..c8aaeb15ece 100644
--- a/gdb/dwarf2/line-program.c
+++ b/gdb/dwarf2/line-program.c
@@ -185,10 +185,11 @@ class lnp_state_machine
   unrelocated_addr m_last_address;
   unsigned int m_last_line = 0;
 
-  /* 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.  */
+  /* The m_stmt_at_address value of the last line entry.  */
+  bool m_stmt_at_last_address = false;
+
+  /* Set to true when this or an earlier entry at the same address has
+     LEF_IS_STMT set in m_flags.  */
   bool m_stmt_at_address = false;
 
   /* When true, record the lines we decode.  */
@@ -430,6 +431,12 @@ dwarf_find_and_extend_inline_block_range (dwarf2_cu *cu,
 void
 lnp_state_machine::record_line (bool end_sequence)
 {
+  /* Track whether we have seen any IS_STMT true at m_address in case we
+     have multiple line table entries all at m_address.  */
+  if (m_last_address != m_address)
+    m_stmt_at_address = false;
+  m_stmt_at_address |= (m_flags & LEF_IS_STMT) != 0;
+
   if (dwarf_line_debug)
     {
       gdb_printf (gdb_stdlog,
@@ -446,7 +453,7 @@ lnp_state_machine::record_line (bool end_sequence)
     }
 
   if (m_address != m_last_address
-      && m_stmt_at_address
+      && m_stmt_at_last_address
       && m_cu->producer_is_gcc ()
       && (m_flags & LEF_IS_STMT) == 0)
     dwarf_find_and_extend_inline_block_range (m_cu, m_last_address,
@@ -501,14 +508,9 @@ lnp_state_machine::record_line (bool end_sequence)
 	}
     }
 
-  /* Track whether we have seen any IS_STMT true at m_address in case we
-     have multiple line table entries all at m_address.  */
-  if (m_last_address != m_address)
-    m_stmt_at_address = false;
-  m_stmt_at_address |= (m_flags & LEF_IS_STMT) != 0;
-
   m_last_address = m_address;
   m_last_line = m_line;
+  m_stmt_at_last_address = m_stmt_at_address;
 }
 
 lnp_state_machine::lnp_state_machine (struct dwarf2_cu *cu, gdbarch *arch)
-- 
2.51.0

[PATCH v2 5/5] [gdb/symtab] Tweak fix-up of truncated inline function block ranges

[Tom de Vries]

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 <xx>) 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 <get_alias_set(tree*)+28>
(gdb)
...
and the backtrace looks like this:
...
 (gdb) bt
 #0  tree_check (i=<optimized out>, t=<optimized out>) at
       step-and-next-inline.cc:43
 #1  get_alias_set (t=t@entry=0x10020030 <xx>) 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 <End of list>
...

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_last_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. ]

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).

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:
...
 <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.

Tested on x86_64-linux and ppc64le-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33930
---
 gdb/dwarf2/line-program.c                         | 15 ++++++++++++++-
 .../gdb.dwarf2/dw2-extend-inline-block.exp        |  5 -----
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/gdb/dwarf2/line-program.c b/gdb/dwarf2/line-program.c
index c8aaeb15ece..9199959c765 100644
--- a/gdb/dwarf2/line-program.c
+++ b/gdb/dwarf2/line-program.c
@@ -452,12 +452,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_last_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);
+					      m_address, m_last_line);
 
   file_entry *fe = current_file ();
 
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-extend-inline-block.exp b/gdb/testsuite/gdb.dwarf2/dw2-extend-inline-block.exp
index 481dfbdd134..dd41a9530c0 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-extend-inline-block.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-extend-inline-block.exp
@@ -600,11 +600,6 @@ foreach test_spec $test_list {
     set build_dwarf_func [lindex $test_spec 1]
     set check_block_func [lindex $test_spec 2]
 
-    if {$build_dwarf_func == "build_dwarf_for_contiguous_block_3"} {
-	# Work around PR gdb/33930.
-	continue
-    }
-
     with_test_prefix $prefix {
 	set asm_file [standard_output_file ${testfile}-${suffix}.S]
 	$build_dwarf_func $asm_file
-- 
2.51.0

[PING][PATCH v2 0/5] [gdb/symtab] Tweak fix-up of truncated inline function block ranges

[Tom de Vries]

On 4/20/26 3:46 PM, Tom de Vries wrote:
> This patch series fixes PR33930, a FAIL in test-case
> gdb.cp/step-and-next-inline.exp on ppc64le-linux.
> 
> The first patch is a simple refactoring patch, renaming
> lnp_state_machine::m_last_line (tracking the last recorded line) to the more
> accurate m_last_recorded_line.
> 
> The second patch reintroduces lnp_state_machine::m_last_line, with semantics
> matching the name (tracking all lines, not just recorded ones).
> 
> The third patch is another refactoring patch, simplifying the conditional
> assignment of lnp_state_machine::m_last_address.
> 
> The fourth patch is yet another refactoring patch, adding
> lnp_state_machine::m_stmt_at_last_address.
> 
> The fifth patch uses lnp_state_machine::m_last_line in the actual fix.
> 

Ping.

Thanks,
- Tom

> A v1 was submitted here [1].
> 
> Changes in v2:
> - add a refactoring patch, simplifying the conditional assignment of
>    lnp_state_machine::m_last_address
> - add a refactoring patch, adding lnp_state_machine::m_stmt_at_last_address
> - remove workaround in gdb.dwarf2/dw2-extend-inline-block.exp
> 
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33930
> 
> [1] v1 https://sourceware.org/pipermail/gdb-patches/2026-March/225480.html
> 
> Tom de Vries (5):
>    [gdb/symtab] Rename lnp_state_machine::m_last_line to
>      m_last_recorded_line
>    [gdb/symtab] Re-add lnp_state_machine::m_last_line
>    [gdb/symtab] Simplify assignment in lnp_state_machine::record_line
>    [gdb/symtab] Add lnp_state_machine::m_stmt_at_last_address
>    [gdb/symtab] Tweak fix-up of truncated inline function block ranges
> 
>   gdb/dwarf2/line-program.c                     | 52 ++++++++++++-------
>   .../gdb.dwarf2/dw2-extend-inline-block.exp    |  5 --
>   2 files changed, 34 insertions(+), 23 deletions(-)
> 
> 
> base-commit: 971b0152e92d381917bb089b3783959c5feb552e