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

[Tom Tromey <tom@tromey.com>]

>>>>> "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.

Tom