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

[Tom Tromey <tom@tromey.com>]

>>>>> "Jan" == Jan Vrany <jan.vrany@labware.com> writes:

Jan> This reverts commit cc1fc6af4150b19f9c4c70d0463ff498703fb637, since it
Jan> causes a number of regressions that seem not to be easily fixable.

I hate to revert this since I think it's a better direction for gdb.

I guess I think the 'lookup' and 'contains' methods should be
equivalent, and neither should ever return the global or static block --
only real code blocks.

Jan> The problem lies in existence of "freestanding" code, a code that is
Jan> part of a CU but does not have any block associated with it. Consider
Jan> following program:
...
Jan> When compiled, the foo function has no block of itself:

FWIW this is what I would expect.  It's just like any other case where a
function does not have debug info: no debug info mean no block.

Jan> Thiago suggested to use minsymbols to tell whether or a CU contains
Jan> given address. I do not think this would work reliably as minsymbols do
Jan> no know to which CU they belong. In slightly more complicated case of
Jan> interleaved CUs it does not seem to be possible to tell for sure to which
Jan> one a given minsymbol belongs.

The don't know the CU but at you should still be able to set a
breakpoint on them.

Anyway, I'd be willing to approve the backout on the basis that it
causes some regression.  But still I question whether it really makes
sense, and if it would be better instead to change the test.

Tom