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
next 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