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

[Leonard Mosescu via lldb-commits]

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