Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>
Subject: [PATCHv2 5/7] gdb: create address map after parsing all DIE
Date: Fri,  1 Aug 2025 09:58:18 +0100	[thread overview]
Message-ID: <044702d9a3dfe49454c7dc821f955bb0a4658e66.1754038556.git.aburgess@redhat.com> (raw)
In-Reply-To: <cover.1754038556.git.aburgess@redhat.com>

Continuing the work done in the last two commits, this commit defers
building the addrmap for a block vector until after all the DIE have
been read, and the line table processed.

The benefit of this is that any changes to a block's ranges done
during line table processing (see the next commit) will be reflected
in the blockvector's addrmap.

The alternative to this is to build the addrmap as we initially see
each block, but then adjust the addrmap if we later decide to modify a
block.  I think defering the addrmap creation is cleaner, and is less
work overall.

The addrmap requires that we add the most inner blocks first.  I
achieve this by walking the blockvector backward, as we always add
parent blocks before their more inner child blocks.

There should be no user visible changes after this commit.
---
 gdb/buildsym.c | 42 +++++++++++++++++++++++++++++++++++++-----
 gdb/buildsym.h | 13 ++++---------
 2 files changed, 41 insertions(+), 14 deletions(-)

diff --git a/gdb/buildsym.c b/gdb/buildsym.c
index 6dc079f29b1..ef50a3d8c18 100644
--- a/gdb/buildsym.c
+++ b/gdb/buildsym.c
@@ -412,8 +412,6 @@ buildsym_compunit::record_block_range (struct block *block,
   if (start != block->start ()
       || end_inclusive + 1 != block->end ())
     m_pending_addrmap_interesting = true;
-
-  m_pending_addrmap.set_empty (start, end_inclusive, block);
 }
 
 struct blockvector *
@@ -449,9 +447,43 @@ buildsym_compunit::make_blockvector ()
   /* If we needed an address map for this symtab, record it in the
      blockvector.  */
   if (m_pending_addrmap_interesting)
-    blockvector->set_map
-      (new (&m_objfile->objfile_obstack) addrmap_fixed
-       (&m_objfile->objfile_obstack, &m_pending_addrmap));
+    {
+      struct addrmap_mutable pending_addrmap;
+      int num_blocks = blockvector->num_blocks ();
+
+      /* If M_PENDING_ADDRMAP_INTERESTING is true then we must have seen
+	 an interesting block.  If we see one block, then we should at a
+	 minimum have a global block, and a static block.  */
+      gdb_assert (num_blocks > 1);
+
+      /* Assert our understanding of how the blocks are laid out.  */
+      gdb_assert (blockvector->block (0)->is_global_block ());
+      gdb_assert (blockvector->block (1)->is_static_block ());
+
+      /* The 'J > 1' here is so that we don't place the global block into
+	 the map.  For CU with gaps, the static block will reflect the
+	 gaps, while the global block will just reflect the full extent of
+	 the range.  */
+      for (int j = num_blocks; j > 1; )
+	{
+	  --j;
+	  struct block *b = blockvector->block (j);
+
+	  gdb_assert (!b->is_global_block ());
+
+	  if (b->is_contiguous ())
+	    pending_addrmap.set_empty (b->start (), (b->end () - 1), b);
+	  else
+	    {
+	      for (const auto &br : b->ranges ())
+		pending_addrmap.set_empty (br.start (), (br.end () - 1), b);
+	    }
+	}
+
+      blockvector->set_map
+	(new (&m_objfile->objfile_obstack) addrmap_fixed
+	 (&m_objfile->objfile_obstack, &pending_addrmap));
+    }
   else
     blockvector->set_map (nullptr);
 
diff --git a/gdb/buildsym.h b/gdb/buildsym.h
index 8f38131ec55..4fd9b61fb5d 100644
--- a/gdb/buildsym.h
+++ b/gdb/buildsym.h
@@ -418,15 +418,10 @@ struct buildsym_compunit
 
   struct subfile *m_current_subfile = nullptr;
 
-  /* The mutable address map for the compilation unit whose symbols
-     we're currently reading.  The symtabs' shared blockvector will
-     point to a fixed copy of this.  */
-  struct addrmap_mutable m_pending_addrmap;
-
-  /* True if we recorded any ranges in the addrmap that are different
-     from those in the blockvector already.  We set this to false when
-     we start processing a symfile, and if it's still false at the
-     end, then we just toss the addrmap.  */
+  /* If there are gaps in the address range of any block associated with
+     this buildsym_compunit, then we need to create an address map, this
+     flag is set true to indicate the addrmap must be created.  If this
+     remains false, then no addrmap will be created.  */
   bool m_pending_addrmap_interesting = false;
 
   /* An obstack used for allocating pending blocks.  */
-- 
2.47.1


  parent reply	other threads:[~2025-08-01  9:04 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-20 10:20 [PATCH 0/7] Inline Function Optimised Code Debug Improvements Andrew Burgess
2025-07-20 10:20 ` [PATCH 1/7] gdb: improve line number lookup around inline functions Andrew Burgess
2025-07-20 10:20 ` [PATCH 2/7] gdb: handle empty ranges for inline subroutines Andrew Burgess
2025-07-20 10:20 ` [PATCH 3/7] gdb: split dwarf line table parsing in two Andrew Burgess
2025-07-20 10:20 ` [PATCH 4/7] gdb: move block range recording into its own function Andrew Burgess
2025-07-20 10:20 ` [PATCH 5/7] gdb: create address map after parsing all DIE Andrew Burgess
2025-07-20 10:20 ` [PATCH 6/7] gdb: record block end addresses while parsing DIEs Andrew Burgess
2025-07-20 10:20 ` [PATCH 7/7] gdb: fix-up truncated inline function block ranges Andrew Burgess
2025-08-01  8:58 ` [PATCHv2 0/7] Inline Function Optimised Code Debug Improvements Andrew Burgess
2025-08-01  8:58   ` [PATCHv2 1/7] gdb: improve line number lookup around inline functions Andrew Burgess
2025-08-01  8:58   ` [PATCHv2 2/7] gdb: handle empty ranges for inline subroutines Andrew Burgess
2025-08-01  8:58   ` [PATCHv2 3/7] gdb: split dwarf line table parsing in two Andrew Burgess
2025-08-01  8:58   ` [PATCHv2 4/7] gdb: move block range recording into its own function Andrew Burgess
2025-08-01  8:58   ` Andrew Burgess [this message]
2025-08-01  8:58   ` [PATCHv2 6/7] gdb: record block end addresses while parsing DIEs Andrew Burgess
2025-08-01  8:58   ` [PATCHv2 7/7] gdb: fix-up truncated inline function block ranges Andrew Burgess
2025-10-16 17:49   ` [PATCHv3 0/7] Inline Function Optimised Code Debug Improvements Andrew Burgess
2025-10-16 17:49     ` [PATCHv3 1/7] gdb: improve line number lookup around inline functions Andrew Burgess
2025-10-27 22:22       ` Tom Tromey
2025-12-17 14:32         ` Andrew Burgess
2025-12-17 14:48           ` Tom de Vries
2025-12-18 14:46             ` Andrew Burgess
2025-10-16 17:49     ` [PATCHv3 2/7] gdb: handle empty ranges for inline subroutines Andrew Burgess
2025-10-16 17:49     ` [PATCHv3 3/7] gdb: split dwarf line table parsing in two Andrew Burgess
2025-10-16 17:49     ` [PATCHv3 4/7] gdb: move block range recording into its own function Andrew Burgess
2025-10-27 22:45       ` Tom Tromey
2025-10-16 17:49     ` [PATCHv3 5/7] gdb: create address map after parsing all DIE Andrew Burgess
2025-10-27 22:56       ` Tom Tromey
2026-01-02 16:36         ` Andrew Burgess
2026-01-05 20:03           ` Tom Tromey
2026-01-05 21:37             ` Andrew Burgess
2026-01-06  0:53               ` Tom Tromey
2025-10-16 17:49     ` [PATCHv3 6/7] gdb: record block end addresses while parsing DIEs Andrew Burgess
2025-10-27 23:00       ` Tom Tromey
2025-10-16 17:49     ` [PATCHv3 7/7] gdb: fix-up truncated inline function block ranges Andrew Burgess
2026-02-04 10:43     ` [PATCHv3 0/7] Inline Function Optimised Code Debug Improvements Andrew Burgess
2025-08-01 15:41 ` [PATCH " Sam James

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=044702d9a3dfe49454c7dc821f955bb0a4658e66.1754038556.git.aburgess@redhat.com \
    --to=aburgess@redhat.com \
    --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