<div dir="ltr"><div>I think I see the problem.  Somewhere I was calling SymbolVendor::FindPlugin(module) instead of module->GetSymbolVendor()</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 29, 2016 at 2:48 PM Greg Clayton <<a href="mailto:clayborg@gmail.com">clayborg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>
<br>
kAllAbilities<br>
<br>
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.<br>
<br>
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.<br>
<br>
No need to do any fancy caching to any other work around.<br>
<br>
Greg<br>
<br>
> On Feb 29, 2016, at 1:26 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> On Mon, Feb 29, 2016 at 10:40 AM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> Thanks!  I think I've got a handle on it.  I'll upload another patch this week hopefully.<br>
><br>
> On Mon, Feb 29, 2016 at 10:30 AM Greg Clayton <<a href="mailto:clayborg@gmail.com" target="_blank">clayborg@gmail.com</a>> wrote:<br>
><br>
> > On Feb 26, 2016, at 3:33 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> ><br>
> > 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.<br>
> ><br>
> > I guess a concrete example would make it clearer.  If I have this code:<br>
> ><br>
> > // foo.cpp<br>
> > #include "foo.h"<br>
> ><br>
> > int main(int argc, char **argv) { return 0; }<br>
> ><br>
> ><br>
> > And I run this C++ code:<br>
> ><br>
> > // After this, sc_list should have 1 entry.<br>
> > ResolveSymbolContext("foo.h", 0, true, eSymbolContextCompUnit, sc_list);<br>
> ><br>
><br>
> 1 entry yes.<br>
><br>
> > // After this, sc_list should have how many entries?  1 or 0?<br>
> > ResolveSymbolContext("foo.h", 0, false, eSymbolContextCompUnit, sc_list);<br>
><br>
> 0 entries unless you actually have a compile unit for "foo.h" where "foo.h" _is_ the main compile unit file.<br>
><br>
> > 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?<br>
> ><br>
> > 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?<br>
><br>
> 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".<br>
><br>
> > (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)<br>
><br>
> 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".<br>
><br>
> Greg<br>
><br>
<br>
</blockquote></div>