<div dir="ltr">Hi Greg,<div><br></div><div>could you clarify the difference between the functions ParseTypes, FindTypes, ResolveTypeUID, and CompleteType from the SymbolFile plugin?</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 14, 2016 at 1:33 PM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Bleh, it looks like some abstraction will be needed at this level too, because ClangASTContext assumes a DWARFASTParser.  <div><br></div><div>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.</div><div><br></div><div>Seem reasonable?</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 14, 2016 at 8:14 AM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It looks like i need to get type information working before variables, so I'll work on that first and come back to this<br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 11, 2016 at 5:05 PM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Mar 11, 2016, at 1:02 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> 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:<br>
><br>
> 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.<br>
> 2. In EntityVariable::Materialize(), we check whether it is valid.<br>
> 3. In SymbolFileDWARF, we "evaluate" the expression.<br>
<br>
Leave this one alone, don't abstract it since it is DWARF native.<br>
<br>
> 4. In a few places, we check whether an input address matches the location specified.<br>
> 5. We dump the location to stdout in a few places.<br>
><br>
> Everything else could just as easily be private methods, because that's all that public users of DWARFExpression actually use.<br>
<br>
Sounds like it won't be too bad.<br>
><br>
> 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.<br>
><br>
> 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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
Greg<br>
<br>
</blockquote></div></blockquote></div></blockquote></div>