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

[Zachary Turner via lldb-commits]

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 <zturner at 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 <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/a135ca9e/attachment-0001.html>