Hi Greg, could you clarify the difference between the functions ParseTypes, FindTypes, ResolveTypeUID, and CompleteType from the SymbolFile plugin?
On Mon, Mar 14, 2016 at 1:33 PM Zachary Turner <ztur...@google.com> wrote: > 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