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


  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