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 <ztur...@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 <ztur...@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 <clayb...@gmail.com> wrote:
>
> > On Feb 26, 2016, at 3:33 PM, Zachary Turner <ztur...@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
>
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
