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

[Zachary Turner via lldb-commits]

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/a06f92b0/attachment.html>