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
