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

Leonard Mosescu via lldb-commits lldb-commits at lists.llvm.org
Tue Dec 11 11:21:37 PST 2018


>
> But if the minidump and PDBs are in the same directory, then wouldn't my
> proposed solution also work (while also being a permanent solution)?
>

If we're looking in the same directory as the binary file (which is how I
read your suggestion) then it would not be found in this case, since the
binary path is coming from the machine where the crash occurred (so there's
no relation with the host where we run LLDB). Using the minidump location
as search path seems an even bigger hack than searching the current
directory.

Speaking of the current directory, I still don't like to use it implicitly
in general, but it's actually consistent with what LLDB does for DWARF (see
Symbols::LocateExecutableSymbolFile). So maybe it's not the terrible hack I
made it look like.

On Tue, Dec 11, 2018 at 10:48 AM Zachary Turner <zturner at google.com> wrote:

> But if the minidump and PDBs are in the same directory, then wouldn't my
> proposed solution also work (while also being a permanent solution)?
>
> On Tue, Dec 11, 2018 at 10:47 AM Leonard Mosescu <mosescu at google.com>
> wrote:
>
>> We talked about this offline, but bringing the discussion back here.  Can
>>> you describe the use case that this is addressing?  As you mention, this is
>>> a temporary hack until we have proper symbol searching logic, but proper
>>> symbol searching logic will do more than just look up symbols in a symbol
>>> server.  It will also, for example, look in the same directory as the
>>> executable file.  If we changed this logic to do that, would your use case
>>> still be addressed?  At least that way, the logic we're adding is not
>>> temporary, even if it will eventually live in a different place (e.g. the
>>> SymbolVendor).
>>>
>>
>> This is intended to provide an easy way to experiment with minidumps +
>> PDBs: just copy the minidump and the PDBs in the same directory (and run
>> lldb from there).
>>
>> It's far from a general solution. I don't think that defaulting to the
>> current directory should even be a hardcoded default - it's just a
>> convenient but temporary hack. I'm open to any alternative ideas we can use
>> until we implement a SymbolVendor.
>>
>> On Tue, Dec 11, 2018 at 10:39 AM Zachary Turner via Phabricator <
>> reviews at reviews.llvm.org> wrote:
>>
>>> zturner added inline comments.
>>>
>>>
>>> ================
>>> Comment at:
>>> source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:139-144
>>> +    llvm::consumeError(expected_binary.takeError());
>>> +    pdb_file = obj_file.GetFileSpec()
>>> +                   .GetFileNameStrippingExtension()
>>> +                   .GetStringRef()
>>> +                   .str();
>>> +    pdb_file += ".pdb";
>>> ----------------
>>> We talked about this offline, but bringing the discussion back here.
>>> Can you describe the use case that this is addressing?  As you mention,
>>> this is a temporary hack until we have proper symbol searching logic, but
>>> proper symbol searching logic will do more than just look up symbols in a
>>> symbol server.  It will also, for example, look in the same directory as
>>> the executable file.  If we changed this logic to do that, would your use
>>> case still be addressed?  At least that way, the logic we're adding is not
>>> temporary, even if it will eventually live in a different place (e.g. the
>>> SymbolVendor).
>>>
>>>
>>> CHANGES SINCE LAST ACTION
>>>   https://reviews.llvm.org/D55142/new/
>>>
>>> https://reviews.llvm.org/D55142
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20181211/daea91d9/attachment.html>


More information about the lldb-commits mailing list