Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-19 Thread 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 wrote: > Bleh, it looks like some abstraction will be needed at this level too, > because ClangASTCo

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-19 Thread Greg Clayton via lldb-dev
> On Mar 16, 2016, at 3:34 PM, Zachary Turner wrote: > > Hi Greg, > > could you clarify the difference between the functions ParseTypes, SymbolFile::ParseTypes() is only used for debugging, don't worry about this one unless you need a way to say "parse all types in the supplied context". It c

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-18 Thread Zachary Turner via lldb-dev
Thanks Greg. It sounds like for now I will need to implement FindTypes and ResolveTypeUID. ParseTypes I can skip and CompleteType can be re-used from the DWARF implementation (it doesn't actually do anything DWARF specific). And FindTypes can probably just re-use ResolveTypeUID and the real work

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-14 Thread 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 th

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-14 Thread 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 wrote: > > > On Mar 11, 2016, at 1:02 PM, Zachary Turner wrote: > > > > How large of a change do you think it would be to abstract

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-11 Thread Greg Clayton via lldb-dev
> On Mar 11, 2016, at 1:02 PM, Zachary Turner 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::UpdateVa

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-11 Thread Zachary Turner via lldb-dev
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

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-11 Thread Greg Clayton via lldb-dev
Feel free to abstract if you need to. The page you sent me to has _very_ simple locations that would convert to DWARF expressions very easily. Probably less that a hundred lines of code. If you need to abstract, making a lldb_private::Location class that DWARFExpression would implement the need

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-11 Thread Zachary Turner via lldb-dev
The only "spec" is the API that allows you to access the info. There's no spec of the bit format. This is probably all you are actually looking for though: The problem isn't necessarily that one is more pwoerful than the other, it's just t

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-11 Thread Greg Clayton via lldb-dev
See my other email. You can abstract this, but it doesn't seem worth it unless PDB has some really powerful way to express variable locations? > On Mar 11, 2016, at 11:39 AM, Zachary Turner via lldb-dev > wrote: > > Can we abstract this somehow? Converting all my debug info to DWARF seems >

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-11 Thread Greg Clayton via lldb-dev
> > Also why does the lldb_private::Variable() class take a DWARFExpression to > its constructor? Seems like this is wrong in the face of non-DWARF debug > information. They are powerful enough to handle any variable location. More powerful than any other format I have seen. You have two choi

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-11 Thread Zachary Turner via lldb-dev
Can we abstract this somehow? Converting all my debug info to DWARF seems like a non-starter, as it doesn't look like you can just do it partially, you have to go all the way (just based on glancing at the DWARFExpression header file) On Fri, Mar 11, 2016 at 11:38 AM Jim Ingham wrote: > lldb us

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-11 Thread Jim Ingham via lldb-dev
lldb uses DWARF expressions internally as a convenient language to represent locations of values. We had to pick some representation, and the DWARF expression was powerful enough for our purposes, meant we didn't have to reinvent something that already existed, and had the added benefit that if

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-11 Thread Greg Clayton via lldb-dev
> On Mar 11, 2016, at 11:02 AM, Zachary Turner via lldb-dev > wrote: > > I'm trying to implement this function for PDB. There are two overloads: > > uint32_t > FindGlobalVariables (const ConstString &name, const CompilerDeclContext > *parent_decl_ctx, bool append, uint32_t max_matches, Varia

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-11 Thread Zachary Turner via lldb-dev
Also why does the lldb_private::Variable() class take a DWARFExpression to its constructor? Seems like this is wrong in the face of non-DWARF debug information. On Fri, Mar 11, 2016 at 11:02 AM Zachary Turner wrote: > I'm trying to implement this function for PDB. There are two overloads: > >

[lldb-dev] SymbolFile::FindGlobalVariables

2016-03-11 Thread Zachary Turner via lldb-dev
I'm trying to implement this function for PDB. There are two overloads: uint32_t FindGlobalVariables (const ConstString &name, const CompilerDeclContext *parent_decl_ctx, bool append, uint32_t max_matches, VariableList& variables) uint32_t FindGlobalVariables(const RegularExpression& regex, bool