[Lldb-commits] [PATCH] D55142: Minidump debugging using the native PDB reader

[Zachary Turner via lldb-commits]

There is another option which I was just made aware of.  LLDB already has a
setting called `target.debug-file-search-paths`.  This is basically a
symbol path.  If you call Symbols::LocateExecutableSymbolFile, it will
already add use this setting, and moreover it will implicitly add current
working directory to this path.

So, if you want this behavior in a supported way that isn't temporary, we
should move the code for findMatchingPDBFile() out of SymbolFilePDB and
into this function.  Then everyone is happy I think.

What do you think?

On Tue, Dec 11, 2018 at 4:42 PM Zachary Turner <zturner at google.com> wrote:

> On Tue, Dec 11, 2018 at 4:22 PM Leonard Mosescu <mosescu at google.com>
> wrote:
>
>> I guess I don't see why we need a temporary solution at all.  If we can
>>> have logic that can be rolled into the SymbolVendor when we get it, and
>>> makes sense there, and is also simple, why not go with it?  Failing that,
>>> doesn't the `target symbols add` solution also work fine?
>>>
>>
>> I just checked again, and "target symbols add" depends on having a real
>> SymbolVendor implementation. So unfortunately we still need a temporary
>> solution.
>>
>
> I tried to verify this behavior, but it seems like it should already work
> out of the box?   So we're on the same page, we already do have a real
> SymbolVendor implementation, it just happens to be the *default*
> SymbolVendor implementation.  It's not the case that one doesn't exist at
> all.
>
> So anyway, when I run "target symbols add foo.exe path/to/foo.pdb"
> internally what this does is set a member variable called m_symfile_spec on
> the Module object.  Then, it calls our normal CalculateAbilities() function
> which calls loadMatchingPDBFile.
>
> I think all that needs to happen is that we need to check this field.  If
> it's empty, try to load a matching PDB file.  If it's set to something,
> then load that file instead.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20181212/180d06d9/attachment.html>