From: Jan Vrany <jan.vrany@labware.com>
To: gdb-patches@sourceware.org
Cc: Jan Vrany <jan.vrany@labware.com>,
Simon Marchi <simon.marchi@efficios.com>
Subject: [pushed] gdb: change blockvector::contains() to handle blockvectors with "holes"
Date: Fri, 28 Nov 2025 13:49:48 +0000 [thread overview]
Message-ID: <20251128134950.1763596-2-jan.vrany@labware.com> (raw)
In-Reply-To: <20251128134950.1763596-1-jan.vrany@labware.com>
This commit slightly changes the logic in blockvector::contains()
to handle a case where the blockvector contains blocks with disjoint
regions (see the comment in blockvector::contains for details).
This change may potentially change GDB's behavior. It is not clear to me
if there was a reason for blockvector_contains_pc() behaving differently
depending whether or not given blockvector contain a map. With this
change, blockvector::contains() return the same value regardless. The
reason for it is to make it work as expected also for "dynamic" code
created by JIT reader (and perhaps by Python in the future).
Note that for CUs created from DWARF, blockvectors have always a map set
so this change in behavior should not affect them. Running testsuite
on Linux x86_64 shown no regressions.
Finally, I was considering of making this change up in lookup method
but in the end decided to be bit more conservative because comment in
original find_block_in_blockvector() suggested that returning a static
block from there is an expected situation.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
---
gdb/block.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/gdb/block.c b/gdb/block.c
index e21580bcf63..3d2c51cc554 100644
--- a/gdb/block.c
+++ b/gdb/block.c
@@ -864,7 +864,34 @@ blockvector::lookup (CORE_ADDR addr) const
bool
blockvector::contains (CORE_ADDR addr) const
{
- return lookup (addr) != nullptr;
+ auto b = lookup (addr);
+ if (b == nullptr)
+ return false;
+
+ /* Handle the case that the blockvector has no address map but still has
+ "holes". For example, consider the following blockvector:
+
+ B0 0x1000 - 0x4000 (global block)
+ B1 0x1000 - 0x4000 (static block)
+ B3 0x1000 - 0x2000
+ (hole)
+ B4 0x3000 - 0x4000
+
+ In this case, the above blockvector does not contain address 0x2500 but
+ lookup (0x2500) would return the blockvector's static block.
+
+ So here we check if the returned block is a static block and if yes, still
+ return false. However, if the blockvector contains no blocks other than
+ the global and static blocks and ADDR falls into the static block,
+ conservatively return true.
+
+ See comment in find_compunit_symtab_for_pc_sect, symtab.c.
+
+ Also, note that if the blockvector in the above example would contain
+ an address map, then lookup (0x2500) would return NULL instead of
+ the static block.
+ */
+ return b != static_block () || num_blocks () == 2;
}
/* See block.h. */
--
2.51.0
next prev parent reply other threads:[~2025-11-28 13:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-28 13:49 [pushed] gdb: update blockvector::lookup Jan Vrany
2025-11-28 13:49 ` Jan Vrany [this message]
2025-12-02 17:41 ` [pushed] gdb: change blockvector::contains() to handle blockvectors with "holes" Tom Tromey
2025-12-02 21:58 ` Jan Vraný
2025-12-03 19:36 ` Tom Tromey
2025-12-03 21:31 ` Jan Vraný
2025-12-04 11:42 ` Tom de Vries
2025-12-04 15:03 ` Jan Vraný
2025-11-28 13:49 ` [pushed] gdb: add unittests for blockvector lookup functions Jan Vrany
2025-11-28 13:49 ` [pushed] gdb: update is_addr_in_objfile to support "dynamic" objfiles Jan Vrany
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=20251128134950.1763596-2-jan.vrany@labware.com \
--to=jan.vrany@labware.com \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@efficios.com \
/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