<div dir="ltr">I guess I could make the CreateInstance() method of SymbolFilePDB do some "smarts" to cache instances of SymbolFilePDB already created, and either return those or create a new one depending on whether we've loaded an instance for the requested executable or not.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 29, 2016 at 1:26 PM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">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></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks!  I think I've got a handle on it.  I'll upload another patch this week hopefully.</div><br><div class="gmail_quote"><div dir="ltr">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></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
</blockquote></div></blockquote></div></blockquote></div>