[Lldb-commits] [PATCH] D17363: Add SymbolFilePDB with basic support for line tables.

[Zachary Turner via lldb-commits]

I think I see the problem.  Somewhere I was calling
SymbolVendor::FindPlugin(module) instead of module->GetSymbolVendor()


On Mon, Feb 29, 2016 at 2:48 PM Greg Clayton <clayborg at gmail.com> wrote:

> You shouldn't have to do any of this. There should be a 1 to 1 mapping
> between a Module and a SymbolVendor which has a single SymbolFile. My guess
> is that you should just return:
>
> kAllAbilities
>
> for SymbolFilePDB::CalculateAbilities (). Try that and let me know how
> this goes. These abilities are bit fields and it becomes hard to compare
> the abilities returned from a symbol file if they don't match.
>
> To make sure you understand: for a given module, we should attempt to find
> a SymbolVendor/SymbolFile 1 time. We will iterate through all SymbolFile
> plugins and pick the one with the best abilities. SymbolFileSymtab might be
> returning a mask of things it can return that are greater than the one
> returned from SymbolFilePDB. So if you return kAllAbilities from
> SymbolFilePDB::CalculateAbilities() it will ensure that SymbolFilePDB is
> picked (make sure no one else is returning this) and your Module should
> have the same SymbolVendor/SymbolFile for the life of the
> lldb_private::Module. If that isn't happening that is a bug that you will
> need to fix. DWARF creates a single instance.
>
> No need to do any fancy caching to any other work around.
>
> Greg
>
> > On Feb 29, 2016, at 1:26 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > I'm running into what I think is the final issue.  My SymbolFilePDB
> plugin creates created many many times.  Specifically, every single call to
> SymbolVendor::FindPlugin(module) will cause a brand new instance of
> SymbolFilePDB to get created.  This effectively kills any caching I've got
> going on, and causes the PDB to get parsed numerous times, but worse is an
> actual bug since I have to be able to persist certain values across calls
> to a plugin for the same executable.
> >
> > Any thoughts how to solve this?  In this particular case that's failing,
> I'm calling SymbolVendor::FindPlugin(module) to get the initial SymbolFile
> plugin, then parsing some things, then calling I'm calling
> LineTable::FindLineEntryByAddress().  This tries to grab the support files,
> but it does so against a brand new instance of SymbolFilePDB, and it's
> impossible for me to do the lookup this way, I need the same SymbolFilePDB
> pointer that I created originally.
> >
> > On Mon, Feb 29, 2016 at 10:40 AM Zachary Turner <zturner at google.com>
> wrote:
> > Thanks!  I think I've got a handle on it.  I'll upload another patch
> this week hopefully.
> >
> > On Mon, Feb 29, 2016 at 10:30 AM Greg Clayton <clayborg at gmail.com>
> wrote:
> >
> > > On Feb 26, 2016, at 3:33 PM, Zachary Turner <zturner at google.com>
> wrote:
> > >
> > > Ok, so back to check_inlines.  I realized after I hit send that the
> explanation I had written out is exactly what I thought I had to do for
> check_inlines == true.
> > >
> > > I guess a concrete example would make it clearer.  If I have this code:
> > >
> > > // foo.cpp
> > > #include "foo.h"
> > >
> > > int main(int argc, char **argv) { return 0; }
> > >
> > >
> > > And I run this C++ code:
> > >
> > > // After this, sc_list should have 1 entry.
> > > ResolveSymbolContext("foo.h", 0, true, eSymbolContextCompUnit,
> sc_list);
> > >
> >
> > 1 entry yes.
> >
> > > // After this, sc_list should have how many entries?  1 or 0?
> > > ResolveSymbolContext("foo.h", 0, false, eSymbolContextCompUnit,
> sc_list);
> >
> > 0 entries unless you actually have a compile unit for "foo.h" where
> "foo.h" _is_ the main compile unit file.
> >
> > > how many entries are in sc_list after the second call?  If it's still
> 1, then what is the difference with the first case?
> > >
> > > Is the only difference what I put into the line tables?  In the 'true'
> case, I fill out the line tables with all the contributions from foo.h, but
> in the 'false' case I don't?  But both still return the same number of
> entries in sc_list?
> >
> > No. You fill in a SymbolContext for each line entry that matches. If
> check_inlines is true, you through the line table for your compile unit
> (where "foo.cpp" is your compile unit's main source file) and search for
> all line entries that match regardless of if "foo.h" == compile unit file
> ("foo.cpp"). If check_inlines is false, then you _only_ look through the
> line table if the file matches your compile unit file (in this case "foo.h"
> != "foo.cpp" so you wouldn't look at _any_ line entries in "foo.cpp".
> >
> > > (Sorry this is so confusing, I'm planning to document this process as
> I go so that the next person that comes along will be able to have all this
> information up front)
> >
> > This option should almost be removed and we should assume "check_inlines
> == true" all the time. It can save time sometimes, but the user really
> always wants "check_inlines == true".
> >
> > Greg
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160229/be743225/attachment.html>