[lldb-dev] SymbolFile::FindGlobalVariables

[Zachary Turner via lldb-dev]

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 <zturner at 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 <gclayton at apple.com> wrote:
>
>>
>> > On Mar 11, 2016, at 1:02 PM, Zachary Turner <zturner at 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160314/50ee0c1a/attachment.html>