Bleh, it looks like some abstraction will be needed at this level too, because ClangASTContext assumes a DWARFASTParser.
This doesn't seem too bad, because the only code that actually assumes it's a DWARFASTParser is in SymbolFileDWARF. So maybe creating a DebugInfoASTParser in lldb/Symbol and then making a PDBASTParser would be enough to get this working. Seem reasonable? On Mon, Mar 14, 2016 at 8:14 AM Zachary Turner <ztur...@google.com> wrote: > It looks like i need to get type information working before variables, so > I'll work on that first and come back to this > On Fri, Mar 11, 2016 at 5:05 PM Greg Clayton <gclay...@apple.com> wrote: > >> >> > On Mar 11, 2016, at 1:02 PM, Zachary Turner <ztur...@google.com> wrote: >> > >> > How large of a change do you think it would be to abstract out the >> location information for the variable? As far as I can tell, our uses of >> this DWARFExpression on Variables are very limited: >> > >> > 1. In ValueObjectVariable::UpdateValue and >> ClangExpressionDeclMap::GetVariableValue, if the location is a constant >> value, it refers to a a host address, we just read the value out as a >> number. >> > 2. In EntityVariable::Materialize(), we check whether it is valid. >> > 3. In SymbolFileDWARF, we "evaluate" the expression. >> >> Leave this one alone, don't abstract it since it is DWARF native. >> >> > 4. In a few places, we check whether an input address matches the >> location specified. >> > 5. We dump the location to stdout in a few places. >> > >> > Everything else could just as easily be private methods, because that's >> all that public users of DWARFExpression actually use. >> >> Sounds like it won't be too bad. >> > >> > This seems like an easy abstraction to create. #3 is irrelevant >> because that code is in SymbolFileDWARF, it could downcast from Location to >> DWARFLocation. #1, 2, 4, and 5 could easily be implemented directly >> against a PDB. >> > >> > While I haven't tried to actually *do* either approach yet, I like the >> idea of creating the abstraction because it provides the native / most >> optimized debugging experience no matter what you're using. For example, I >> can easily imagine a scenario where I have to keep the PDB open in memory >> to query some types of information, but I have to do a conversion of >> location information for Variables, and the memory usage becomes >> unacceptable because everything is memory twice (even though it's lazily >> evaluated, the memory usage would double over time). >> >> You will abstract the location only and that is fine. For everything else >> we do have lldb classes that will need to be created (compile units, >> functions, blocks, variables). Types are done via the TypeSystem subclasses >> so you will need convert all types there. So feel free to abstract the >> DWARFExpression for variable locations only. >> >> I have no problem with the abstraction if you think it is needed. I >> personally think it will be much more work, but I won't be doing it so I >> don't mind. >> >> Greg >> >>
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
