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

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

On Tue, 2025-12-02 at 10:41 -0700, Tom Tromey wrote:
> > > > > > "Jan" == Jan Vrany <jan.vrany@labware.com> writes:
> 
> Jan> Finally, I was considering of making this change up in lookup method
> Jan> but in the end decided to be bit more conservative because comment in
> Jan> original find_block_in_blockvector() suggested that returning a static
> Jan> block from there is an expected situation.
> 
> 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...

I agree, I just do not really understand why there was the difference in first place.
In fact, it seems that it matters - I've got a report that this commit caused
regression on arm (still investigating, I do not have armhf system at hand, so
need to set it up first).

Jan

> 
> Anyway I consider this important for supporting expandable blockvectors,
> which in turn is important for lazy CU expansion.
> 
> Tom