This is an archive of the discontinued LLVM Phabricator instance.

[PDB] Fix location retrieval for function local variables and arguments that are stored relative to VFRAME
ClosedPublic

Authored by leonid.mashinskiy on Nov 30 2018, 6:43 AM.

Details

Summary

This patch makes LLDB able to retrieve proper values for function arguments and local variables stored in PDB relative to VFRAME register.

Patch contains retrieval of corresponding FPO table entries from PDB and a generic translator from FPO programs to DWARF expressions to get correct VFRAME value.

Patch also improves variables-locations.test and makes this test passable on x86.

Related to D53086

Diff Detail

Repository
rL LLVM

Event Timeline

labath added a subscriber: labath.Nov 30 2018, 9:22 AM

I like how you've separated out the conversion function doing the actual conversion. That should make it easy to write unit tests for it (including tests for malformed input). Can you add something like that? I am particularly interested in what will the merging code do when it encounters reference loops.

However, I find the usage of shared_ptr in the parsing code overkill. Surely we can come up with something better when the lifetime of all of the objects is local to the translation function. I think the most llvm-y solution would be to use a BumpPtrAllocator to create all nodes, and then just dispose of that when the function returns. (this assumes the nodes are trivially destructible, which it looks like they will be after they stop storing shared_ptrs).

source/Plugins/SymbolFile/PDB/PDBFPOProgramToDWARFExpression.cpp
203 ↗(On Diff #176109)

use llvm::DenseMap ?

Added unit tests for translator and fix issues mentioned by review

Seems like we can't move to NativePDB plugin right now, because there are still not implemented some methods like ParseVariablesForContext which this code integration based on.
But when it will - we can easily do the transition.

I can do it, but unfortunately not this week... I want to join the native plugin development some later, at the end of this month, after some current work.

labath added a comment.Dec 4 2018, 3:19 AM

Thank you. I like the tests a lot. I think I'll steal the implementation of this when I get around to parsing breakpad unwind instructions. ;)

This looks fine to me, but one of the windows folks should take a look at it too.

source/Plugins/SymbolFile/PDB/PDBFPOProgramToDWARFExpression.cpp
336–337 ↗(On Diff #176411)
483–487 ↗(On Diff #176411)

Is this true? Is it not possible for a program to depend on a value of a register which will be defined later?

  • add more tests on dependent programs
  • handle parsing of cyclically dependent programs properly
  • remove default cases for fully covered enums as mentioned in conding standart

Is this true? Is it not possible for a program to depend on a value of a register which will be defined later?

I am not totally sure about this, but all valid fpo programs that I've seen in existing pdb support this invariant.
So I think that we can assume that every assignment depends only to precedent statements.

labath added a comment.Dec 4 2018, 4:41 AM

Is this true? Is it not possible for a program to depend on a value of a register which will be defined later?

I am not totally sure about this, but all valid fpo programs that I've seen in existing pdb support this invariant.
So I think that we can assume that every assignment depends only to precedent statements.

Ok, that's fine with me, I just wanted to check that was intentional. It might be worth mentioning that in a comment somewhere.

leonid.mashinskiy set the repository for this revision to rLLDB LLDB.
  • Ported implementation to NativePDB plugin.
  • Implemented GetVariableLocationInfo for local variables of S_DEFRANGE_FRAMEPOINTER_REL and S_DEFRANGE_REGISTER_REL type

As D56725 committed, can you please look at latest changes here?

zturner accepted this revision.Jan 30 2019, 9:07 AM

This is really cool, thanks for doing this!

source/Expression/DWARFExpression.cpp
3253 ↗(On Diff #181792)

Why do we change the return value here?

source/Plugins/SymbolFile/NativePDB/CodeViewRegisterMapping.h
16 ↗(On Diff #181792)

Can you put this function in the lldb_private::npdb namespace?

source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.h
20 ↗(On Diff #181792)

Can you put this function in the lldb_private::npdb namespace?

This revision is now accepted and ready to land.Jan 30 2019, 9:07 AM
leonid.mashinskiy marked an inline comment as done.
  • made changes related to review
source/Expression/DWARFExpression.cpp
3253 ↗(On Diff #181792)

This function had mixed return value semantics and I changed it to always returning true on success and false on failure.
Nobody checked return value before and I use it in unit tests.

leonid.mashinskiy marked 2 inline comments as done.Jan 31 2019, 2:02 AM

Thanks for review!
Please, commit this for me, because I have no commit access.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 1 2019, 2:01 AM
labath added a comment.Feb 7 2019, 9:15 AM

It looks like the files you've added here still have the old headers. Could you please update that?

Fixed in r353503, thanks!