aleksandr.urakov added a comment.
I think both approaches are acceptable, but I would prefer to include it into
the Symbols library because this functionality is more symbols-related than
general.
Repository:
rLLDB LLDB
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D60068/new/
https
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB357455: PDBFPO: Refactor register reference resolution
(authored by labath, committed by ).
Herald added a subscriber: abidh.
Herald added a project: LLDB.
Changed prior to commit:
https://reviews.ll
labath marked an inline comment as done.
labath added a comment.
Thanks.
BTW, do you have any thoughts where this code could live (it can't stay here
because I need to access it from SymbolFileBreakpad too). I was thinking of the
Symbol library, as both users are `SymbolFile`s.
I don't think t
aleksandr.urakov accepted this revision.
aleksandr.urakov added a comment.
LGTM!
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D60068/new/
https://reviews.llvm.org/D60068
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://list
amccarth accepted this revision.
amccarth added inline comments.
Comment at:
source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp:287
+
+ // lookup register reference as lvalue in preceding assignments
+ auto it = m_dependent_programs.find(symbol->GetName());
labath created this revision.
labath added reviewers: aleksandr.urakov, zturner, amccarth.
Herald added a subscriber: jdoerfert.
This refactors moves the register name->number resolution out of the
FPOProgramNodeRegisterRef class. Instead I create a special
FPOProgramNodeSymbol class, which holds
