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] [gdb] Fix hard-coded constants in buildsym_compunit::make_blockvector
Date: Thu, 16 Jul 2026 18:56:59 +0200	[thread overview]
Message-ID: <20260716165659.1416919-1-tdevries@suse.de> (raw)

I came across some code in buildsym_compunit::make_blockvector that uses
hardcoded constants 0 and 1:
...
      gdb_assert (blockvector->block (0)->is_global_block ());
      gdb_assert (blockvector->block (1)->is_static_block ());
...

Fix this by instead using the symbolic constants GLOBAL_BLOCK and
STATIC_BLOCK.

The same function has an odd-looking for loop that uses a hard-coded '1' to
skip the global 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);
...

Fix this by rewriting it into an ordinary descending for loop, and using
symbolic constant GLOBAL_BLOCK to avoid the global block:
...
      for (int j = num_blocks - 1; j > GLOBAL_BLOCK; --j)
 	{
 	  struct block *b = blockvector->block (j);
...
---
 gdb/buildsym.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/gdb/buildsym.c b/gdb/buildsym.c
index b543cd10eb5..2b0a9a39b81 100644
--- a/gdb/buildsym.c
+++ b/gdb/buildsym.c
@@ -363,16 +363,15 @@ buildsym_compunit::make_blockvector ()
       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 ());
+      gdb_assert (blockvector->block (GLOBAL_BLOCK)->is_global_block ());
+      gdb_assert (blockvector->block (STATIC_BLOCK)->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 'J > GLOBAL_BLOCK' 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; )
+      for (int j = num_blocks - 1; j > GLOBAL_BLOCK; --j)
 	{
-	  --j;
 	  struct block *b = blockvector->block (j);
 
 	  gdb_assert (!b->is_global_block ());

base-commit: a4481c8ff808e7237b99815d84b0d4c06ded6124
-- 
2.51.0


             reply	other threads:[~2026-07-16 16:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-16 16:56 Tom de Vries [this message]
2026-07-17 14:20 ` Tom Tromey

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=20260716165659.1416919-1-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