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

[Zachary Turner via lldb-commits]

I meant the location of the minidump.  So if you have C:\A\B\C\foo.dmp
which is the dump file for bar.exe which crashed on another machine, then
it would look for C:\A\B\C\bar.pdb.  That actually seems like fairly
intuitive behavior to me, but maybe I'm in the minority :)

We can see what Pavel, Adrian, and others think though or if they have any
other suggestions.

On Tue, Dec 11, 2018 at 11:21 AM Leonard Mosescu <mosescu 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)?
>>
>
> 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/a48fe797/attachment-0001.html>