Cannot retrieve existing lines with lines_at_offset about pdb HOT 3 CLOSED

After thinking about that: if my reasoning is correct, then it means we should keep a sorted Vec of (PdbInternalSectionOffset, DebugSubsection) (sorted on offset) and then make a binary search to get the correct DS.
It should fix in the mean time the complexity of lines_at_offset (which is currently linear) which should become log (I'd have prefer constant but doesn't seem possible).

from pdb.

We can probably merge this with the fix for #61. The fix would be pretty much what you proposed, except I would propose a BTreeMap<Offset, DS>.

However, in PDBs there is always a separate subsection per function. So if you search for the function's start offset, you should always have an exact hit. What is the offset that you're feeding into lines_at_offset? This obviously includes the function epilogue, which might account for the difference of 0x10.

from pdb.

I used lines_at_offset with proc_symbol.offset (ie: {s: 0x1, o: 0x8990}).
I printed DebugLinesSubsections for this line_program (this is the only one):
DebugLinesSubsection { header: DebugLinesHeader { offset: PdbInternalSectionOffset { section: 0x1, offset: 0x8980 }, flags: 0, code_size: 49 }, data: [0, 0, 0, 0, 9, 0, 0, 0, 84, 0, 0, 0, 16, 0, 0, 0, 45, 0, 0, 128, 16, 0, 0, 0, 47, 0, 0, 128, 23, 0, 0, 0, 48, 0, 0, 128, 26, 0, 0, 0, 49, 0, 0, 128, 30, 0, 0, 0, 50, 0, 0, 128, 35, 0, 0, 0, 51, 0, 0, 128, 38, 0, 0, 0, 52, 0, 0, 128, 40, 0, 0, 0, 62, 0, 0, 128, 44, 0, 0, 0, 66, 0, 0, 128] }

So it seems that it's "almost always" or maybe I'm doing something wrong.

from pdb.