Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot retrieve existing lines with lines_at_offset #63

Closed
calixteman opened this issue Sep 23, 2019 · 3 comments · Fixed by #68
Closed

Cannot retrieve existing lines with lines_at_offset #63

calixteman opened this issue Sep 23, 2019 · 3 comments · Fixed by #68

Comments

@calixteman
Copy link
Contributor

In inspecting a basic PDB (almost a basic helloworld program compiled with clang on windows), there is a proc symbol for _security_check_cookie (the code should be almost this one: https://github.com/adityaramesh/concurrency_runtime/blob/master/VS2013_SP2/crt/src/AMD64/amdsecgs.asm).
The InternalSectionOffset is {s: 0x1, o: 0x8990} but when I try to get line info I got nothing.
The reason is that the InternalSectionOffset for lines is at {s: 0x1, o: 0x8980}.
My hypothesis is that the executable code is really at 0x8990 (line 47) and there are metadata or padding or whatever at 0x8980.
For info, the code_size of the proc is 33 where it appears to be 49 (33 + 16) in DbgLineSub.
So, I'd say that we shouldn't get "lines_section.header.offset == offset" but take the max before offset.
If you need to have the pdb, then I can share it with you.

@calixteman
Copy link
Contributor Author

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

@jan-auer
Copy link
Member

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.

@calixteman
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants