<div dir="ltr">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 :)<div><br></div><div>We can see what Pavel, Adrian, and others think though or if they have any other suggestions.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 11:21 AM Leonard Mosescu <<a href="mailto:mosescu@google.com">mosescu@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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">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)?<br></blockquote><div><br></div></div><div dir="ltr"><div>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.</div><div dir="ltr"><br></div><div dir="ltr">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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 10:48 AM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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)?</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 10:47 AM Leonard Mosescu <<a href="mailto:mosescu@google.com" target="_blank">mosescu@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div dir="ltr"><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" target="_blank">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>
</blockquote></div>
</blockquote></div>
</blockquote></div>