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

[Zachary Turner via lldb-commits]

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