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.
On Mon, 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