[lldb-dev] SymbolFile::FindGlobalVariables

[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
<https://msdn.microsoft.com/en-us/library/wwkta258.aspx> 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 that PDBs can get huge (on the order of gigabytes), and
converting between formats is an unnecessary step that a) will be slow to
do the conversion, b) might not map 1 to 1 between the formats, and c) it'
already trivial (on the order of a few lines of code) to just query the PDB
for everything you need.

So we're talking about potentially thousands of lines of code to do
something that would take about 10 (as well as being more efficient) with a
proper abstraction.

On Fri, Mar 11, 2016 at 11:43 AM Greg Clayton <gclayton at apple.com> wrote:

> 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 <
> lldb-dev at lists.llvm.org> wrote:
> >
> > 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 <jingham at apple.com> wrote:
> > 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 you did your DWARF then you don't have to transcode.
> >
> > Jim
> >
> > > On Mar 11, 2016, at 11:32 AM, Zachary Turner via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> > >
> > > 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 <zturner at google.com>
> 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,
> VariableList& variables)
> > >
> > > uint32_t
> > > FindGlobalVariables(const RegularExpression& regex, bool append,
> uint32_t max_matches, VariableList& variables)
> > >
> > > I know how to implement the second overload, but not the first.  What
> is a CompilerDeclContext?  Some comments in the DWARF implementation of the
> function seem to imply it's related to namespaces, but there's a lot of
> strange code that I don't understand.  What is the relationship between a
> namespace and a symbol file?  And why does
> `DeclContextMatchesThisSymbolFile` contain no code at all that accesses any
> property of the symbol file?  It just checks if
> decl_ctx->GetTypeSystem()->GetMinimumLanguage(nullptr) ==
> decl_ctx->GetTypeSystem(), which appears to have nothing to do with any
> symbol file.
> > >
> > > What user command or debugger operation results in FindGlobalVariables
> getting called with this particular overload, and how does it build the
> CompilerDeclContext?
> > >
> > > On another note, why is the decl context stored as void* instead of
> having an actual wrapper with an abstract interface such as
> ClangDeclContext / JavaDeclContext, etc that all inherit from
> LanguageDeclContext, and pass the LanguageDeclContext around instead of a
> void*?
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb-dev at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160311/64ded61f/attachment-0001.html>