Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH v2 4/5] [gdb/symtab] Add lnp_state_machine::m_stmt_at_last_address
Date: Mon, 20 Apr 2026 15:46:07 +0200	[thread overview]
Message-ID: <20260420134608.2537059-5-tdevries@suse.de> (raw)
In-Reply-To: <20260420134608.2537059-1-tdevries@suse.de>

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


  parent reply	other threads:[~2026-04-20 13:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-20 13:46 [PATCH v2 0/5] [gdb/symtab] Tweak fix-up of truncated inline function block ranges Tom de Vries
2026-04-20 13:46 ` [PATCH v2 1/5] [gdb/symtab] Rename lnp_state_machine::m_last_line to m_last_recorded_line Tom de Vries
2026-04-20 13:46 ` [PATCH v2 2/5] [gdb/symtab] Re-add lnp_state_machine::m_last_line Tom de Vries
2026-04-20 13:46 ` [PATCH v2 3/5] [gdb/symtab] Simplify assignment in lnp_state_machine::record_line Tom de Vries
2026-04-20 13:46 ` Tom de Vries [this message]
2026-04-20 13:46 ` [PATCH v2 5/5] [gdb/symtab] Tweak fix-up of truncated inline function block ranges Tom de Vries
2026-07-29 11:01 ` [PING][PATCH v2 0/5] " Tom de Vries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260420134608.2537059-5-tdevries@suse.de \
    --to=tdevries@suse.de \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox