Re: [PATCH 5/7] gdb: update blockvector::lookup to handle non-contiguous blocks

[Tom Tromey <tom@tromey.com>]

>> I glossed over this before but is this patch in this series?

Jan> No, this is the patch "Fix debug_names function visibility" from your 
Jan> branch you said you'll check in [1]. I can include it if you prefer.

Jan> [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=33829#c12

Oops, I forgot about this.  I'll send it shortly.

Jan> Other option I was thinking was to change make_blockranges to always sort then,
Jan> then the assertions in set_ranges would be trivial and in block::contains one
Jan> can binary-search block ranges too (though for up to ~4 ranges perhaps not worth).

Lately I've been thinking that weirdness should be hidden in the readers
and not exposed to the core.  But putting stuff like this in "builder"
code also seems fine.  The main point is that core/generic code
shouldn't have to cope with weirdness in the data structures, that
should be ironed out when creating them.

Jan> TBH I have no idea. How common is this, how many ranges blocks have, nor
Jan> how to force compiler to produce such binary. Maybe torturing the compiler
Jan> with -O3 and PGO?

Yeah, maybe just an optimized LTO build of gdb would show it.

Tom