Re: [pushed] gdb: change blockvector::contains() to handle blockvectors with "holes"

["Jan Vraný" <Jan.Vrany@labware.com>]

On Thu, 2025-12-04 at 12:42 +0100, Tom de Vries wrote:
> On 12/3/25 10:31 PM, Jan Vraný wrote:
> > On Wed, 2025-12-03 at 12:36 -0700, Tom Tromey wrote:
> > > > > > > > "Jan" == Jan Vraný <Jan.Vrany@labware.com> writes:
> > > 
> > > > > FWIW it seems to me that the blockvector should just have a single
> > > > > lookup function, and it should be used to find precisely the code block
> > > > > containing the given address.  That is, it should never return the
> > > > > static or global block, since those aren't really "code" but instead
> > > > > just containing scopes.  This is the direction I was trying to head by
> > > > > removing calls to map(); the one remaining call is one of these weird
> > > > > ones...
> > > 
> > > Jan> I agree, I just do not really understand why there was the
> > > Jan> difference in first place.
> > > 
> > > I don't really, either.  That code is pretty old, though, and some of
> > > the older code is pretty questionable.  Like sometimes problems with
> > > debug readers were worked around in core code rather than being solved
> > > in the reader, abstractions were very leaky (or in this case
> > > nonexistent), etc.
> > > 
> > > Jan> In fact, it seems that it matters - I've got a report that this
> > > Jan> commit caused regression on arm (still investigating, I do not have
> > > Jan> armhf system at hand, so need to set it up first).
> > > 
> > > My current attempt at cleanups here also run into some regressions that
> > > I wasn't really expecting :(
> > > 
> > > Anyway I'd find it interesting to learn what the ARM regression is
> > > about.
> > 
> > Yeah, it's weird. The report is here:
> > 
> > https://linaro.atlassian.net/browse/GNU-1767
> > 
> > I did not yet managed to reproduce it. It does not seem to manifest Debian
> > armhf running on QEMU. I'm not familiar with ARM ecosystem myself and
> > I do not know yet how to arrive at working "armv8l" system. I'll let you
> > know when I learn more but just now I'm running out of ideas on how to
> > debug this :(
> > 
> 
> I bisected this PR ( 
> https://sourceware.org/bugzilla/show_bug.cgi?id=33679 ) to this commit.
> 
> Are the regressions you mention the same issue?

Yes! "gdb.base/annota1.exp: send SIGUSR1 (timeout)" is one of the failing tests.

Thanks a lot!

Jan