]> git.feebdaed.xyz Git - 0xmirror/binutils-gdb.git/commit
gdb: change blockvector::contains() to handle blockvectors with "holes"
authorJan Vrany <jan.vrany@labware.com>
Fri, 28 Nov 2025 13:47:02 +0000 (13:47 +0000)
committerJan Vrany <jan.vrany@labware.com>
Fri, 28 Nov 2025 13:47:02 +0000 (13:47 +0000)
commitcc1fc6af4150b19f9c4c70d0463ff498703fb637
treeffb595e4e72d7aa14c2f972ee10774017cfb9029
parent116ea63b99b55a1cd16bb87eb8631aed426f4b0a
gdb: change blockvector::contains() to handle blockvectors with "holes"

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