From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH 09/10] [gdb] Add block::block_and_superblocks_in_fn
Date: Fri, 1 May 2026 14:45:03 +0200 [thread overview]
Message-ID: <20260501124504.2233495-10-tdevries@suse.de> (raw)
In-Reply-To: <20260501124504.2233495-1-tdevries@suse.de>
Add a function block::block_and_superblocks_in_fn that can be used to
transform:
...
while (block != NULL)
{
...
if (block->function () != nullptr)
break;
block = block->superblock ();
}
...
into:
...
for (auto b : block::block_and_superblocks_in_fn (block))
{
...
}
...
In fact the new loop is somewhat stricter, because it systematically ignores
the static and global blocks.
This means that the transformation is not strictly semantics-preserving. I'm
still on the fence about whether this is a good idea.
My assumption here is that these loops are written assuming a well-formed
block hierarchy:
...
global block <- static block <- function block <- in-function block
...
as well as assuming that the starting block is not the static or global block.
And for such loops, the stricter static/global blocks skipping behavior
doesn't matter.
---
gdb/block.h | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/gdb/block.h b/gdb/block.h
index ff5203ae4c6..c39425185aa 100644
--- a/gdb/block.h
+++ b/gdb/block.h
@@ -127,7 +127,42 @@ struct block : public allocate_on_obstack<block>
}
};
+ /* Variant of next_iterator using the superblock field instead of next. */
+ struct function_block_iterator
+ : base_next_iterator<const block, function_block_iterator>
+ {
+ typedef function_block_iterator self_type;
+
+ explicit function_block_iterator (value_type item)
+ : base_next_iterator (item->is_global_block () || item->is_static_block ()
+ ? nullptr : item)
+ {
+ }
+
+ function_block_iterator () = default;
+
+ value_type next ()
+ {
+ if (m_item->function () != nullptr)
+ return nullptr;
+
+ value_type next = m_item->superblock ();
+ if (next->is_global_block () || next->is_static_block ())
+ {
+ /* This shouldn't be reachable in well-formed block hierarchies, given
+ that we avoid global and static block in the constructor, and
+ stop iterating when encountering a function. But let's try to be
+ robust and ensure that this iterator never points to a static or
+ global block. */
+ return nullptr;
+ }
+
+ return next;
+ }
+ };
+
using superblock_range = iterator_range<superblock_iterator>;
+ using function_block_range = iterator_range<function_block_iterator>;
/* Return this block's start address. */
CORE_ADDR start () const
@@ -352,6 +387,27 @@ struct block : public allocate_on_obstack<block>
return b->block_and_superblocks ();
}
+ /* Return a range adapter that iterates over this block and its
+ superblocks in the same function. */
+
+ function_block_range block_and_superblocks_in_fn () const
+ {
+ function_block_range::iterator begin (this);
+
+ return function_block_range (std::move (begin));
+ }
+
+ /* Return a range adapter that iterates over B and its superblocks in the
+ same function. */
+
+ static function_block_range block_and_superblocks_in_fn (const block *b)
+ {
+ if (b == nullptr)
+ return function_block_range ();
+
+ return b->block_and_superblocks_in_fn ();
+ }
+
/* Return true if block A is lexically nested within this block, or
if A and this block have the same pc range. Return false
otherwise. If ALLOW_NESTED is true, then block A is considered
--
2.51.0
next prev parent reply other threads:[~2026-05-01 12:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 12:44 [PATCH 00/10] [gdb] Add superblocks range loops Tom de Vries
2026-05-01 12:44 ` [PATCH 01/10] [gdb] Use block::containing_function Tom de Vries
2026-05-01 12:44 ` [PATCH 02/10] [gdb] Factor out block::containing_function_block Tom de Vries
2026-05-01 12:44 ` [PATCH 03/10] [gdb] Use block::containing_function_block Tom de Vries
2026-05-01 12:44 ` [PATCH 04/10] [gdb] Add unit test for next_iterator Tom de Vries
2026-05-01 12:44 ` [PATCH 05/10] [gdbsupport] Use using instead of typedef in next_iterator Tom de Vries
2026-05-01 12:45 ` [PATCH 06/10] [gdbsupport] Factor out base_next_iterator Tom de Vries
2026-05-08 19:17 ` Tom Tromey
2026-05-01 12:45 ` [PATCH 07/10] [gdb] Add block::block_and_superblocks Tom de Vries
2026-05-01 12:45 ` [PATCH 08/10] [gdb] Use block::block_and_superblocks Tom de Vries
2026-05-08 19:41 ` Tom Tromey
2026-05-01 12:45 ` Tom de Vries [this message]
2026-05-01 12:45 ` [PATCH 10/10] [gdb] Use block::block_and_superblocks_in_fn Tom de Vries
2026-06-09 12:40 ` [PATCH 00/10] [gdb] Add superblocks range loops 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=20260501124504.2233495-10-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