[lldb-dev] SymbolFile::FindGlobalVariables

[Zachary Turner via lldb-dev]

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/5d1dc7e0/attachment.html>