Re: [lldb-dev] SymbolFile::FindGlobalVariables

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,

Re: [lldb-dev] SymbolFile::FindGlobalVariables

> 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

Re: [lldb-dev] SymbolFile::FindGlobalVariables

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

Re: [lldb-dev] SymbolFile::FindGlobalVariables

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

Re: [lldb-dev] SymbolFile::FindGlobalVariables

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

Re: [lldb-dev] SymbolFile::FindGlobalVariables

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

Re: [lldb-dev] SymbolFile::FindGlobalVariables

> > 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

Re: [lldb-dev] SymbolFile::FindGlobalVariables

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

Re: [lldb-dev] SymbolFile::FindGlobalVariables

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

Re: [lldb-dev] SymbolFile::FindGlobalVariables

> 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 , const CompilerDeclContext > *parent_decl_ctx, bool append,

Re: [lldb-dev] SymbolFile::FindGlobalVariables

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

[lldb-dev] SymbolFile::FindGlobalVariables

I'm trying to implement this function for PDB. There are two overloads: uint32_t FindGlobalVariables (const ConstString , const CompilerDeclContext *parent_decl_ctx, bool append, uint32_t max_matches, VariableList& variables) uint32_t FindGlobalVariables(const RegularExpression& regex, bool