<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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).  <br></blockquote><div><br></div><div>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). </div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 10:39 AM Zachary Turner via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">zturner added inline comments.<br>
<br>
<br>
================<br>
Comment at: source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:139-144<br>
+    llvm::consumeError(expected_binary.takeError());<br>
+    pdb_file = obj_file.GetFileSpec()<br>
+                   .GetFileNameStrippingExtension()<br>
+                   .GetStringRef()<br>
+                   .str();<br>
+    pdb_file += ".pdb";<br>
----------------<br>
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).<br>
<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D55142/new/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D55142/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D55142" rel="noreferrer" target="_blank">https://reviews.llvm.org/D55142</a><br>
<br>
<br>
<br>
</blockquote></div>