aboutsummaryrefslogtreecommitdiff
path: root/gdbserver/win32-low.cc
diff options
context:
space:
mode:
authorJan Vrany <jan.vrany@labware.com>2025-11-28 13:47:02 +0000
committerJan Vrany <jan.vrany@labware.com>2025-11-28 13:47:02 +0000
commitcc1fc6af4150b19f9c4c70d0463ff498703fb637 (patch)
treeffb595e4e72d7aa14c2f972ee10774017cfb9029 /gdbserver/win32-low.cc
parent116ea63b99b55a1cd16bb87eb8631aed426f4b0a (diff)
downloadbinutils-cc1fc6af4150b19f9c4c70d0463ff498703fb637.zip
binutils-cc1fc6af4150b19f9c4c70d0463ff498703fb637.tar.gz
binutils-cc1fc6af4150b19f9c4c70d0463ff498703fb637.tar.bz2
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>
Diffstat (limited to 'gdbserver/win32-low.cc')
0 files changed, 0 insertions, 0 deletions