[lldb-dev] SymbolFile::FindGlobalVariables

[Zachary Turner via lldb-dev]

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 <zturner at 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 <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/20160316/dbb630a2/attachment.html>