<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 here, we're talking about a situation where there is no EXE, only a minidump.  If there is a minidump and no EXE then neither WinDbg nor VS will search the minidump folder for the PDB.   </blockquote><div><br></div><div>Indeed, this is key part.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> In my mind, the algorithm could be something like: ...<br></blockquote><div><br></div><div>I'm not a big fan of this kind of magic. VS sometime does it, and while it's nice in the 80% of the cases I found it hard to troubleshoot when something goes wrong. For what it's worth, recent versions of VC++ debugger are more aligned with ntsd/cdb/windbg.<br></div><div><br></div><div>Anyway, for this patch I think the question is: what's the simplest temporary solution? All of these ideas are interesting but more appropriate to evaluate when we start designing the PDB SymbolVendor.</div><div><br></div><div> </div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 3:05 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Only one way to know for sure, and that's to test it :)  So I did.<div><br></div><div>Yes, it will search the directory of the EXE for the PDB.  But here, we're talking about a situation where there is no EXE, only a minidump.  If there is a minidump and no EXE then neither WinDbg nor VS will search the minidump folder for the PDB.  Personally I think it should and I wouldn't mind if that were a documented and tested feature of LLDB, because since it already is established behavior to search the minidump folder for the EXE, it doesn't seem hacky at all for it to also search that location for the PDB.  In my mind, the algorithm could be something like:</div><div><br></div><div>```</div><div>if (ExeLocation = FindExecutableInMinidumpFolder()) {</div><div>  PdbLocation = FindPdbFromExecutable(ExeLocation)</div><div>} else {</div><div>  PdbLocation = FindPdbInMinidumpFolder();</div><div>  if (!PdbLocation)</div><div>    PdbLocation = FindPdbInSympath();</div><div>}</div><div>```</div><div><br></div><div>and that would be pretty logical and not code that we would have to consider temporary.</div><div><br></div><div>My main pushback here is that it's harder to remove code than it is to add it, because once you add it, someone is going to depend on it and complain when you try to remove it.  So if we can just establish some behavior that satisfies the use case while not being temporary, I would prefer to do it.</div><div><br></div><div>Another option I can think of is to just run `target symbols add -s foo.exe foo.pdb`.  I think we would need to have SymbolFileNativePDB check the value of this setting, but using this workflow, you could just put a .lldbinit file next to lldb.exe that runs this command at startup.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 2:17 PM Adrian McCarthy <<a href="mailto:amccarth@google.com" target="_blank">amccarth@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I believe the PDB is searched for in the EXE directory before the symbol search path is used.  At least, that's what it used to do, back when I used VS debugger for post-mortem debugging.  It was the only sane way to ensure it would find the right version of the PDB if you didn't have a local symbol server.<div><br></div><div>Yes, I understand that the security note was about DLL loading.  My point was that, in general, Windows looks in well known places first, before checking the current working directory.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 2:12 PM Leonard Mosescu <<a href="mailto:mosescu@google.com" target="_blank">mosescu@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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"><div>The Windowsy thing to do is what Zach said:  Check the directory that contains the .dmp for the .pdb.  It's the first place the VS debugger looks when opening a minidump.  It's less sensitive to the user's environment.  (Making the user change the current working directory for this could be at odds with other bits of the software that look relative the cwd.)</div><div><a href="https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Find_binaries__symbol___pdb__files__and_source_files" target="_blank">https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Find_binaries__symbol___pdb__files__and_source_files</a><br></div></blockquote><div><br></div>Except that it doesn't :) Neither VisualStudio nor the Windows Debuggers (windbg & co) look for PDBs in the same directory as the dump file. The search is controlled by an explicit "symbol search path". The link you mentioned is a bit confusing indeed (although it only claims that the .exe's are searched in the same directory as the .dmp)<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>While security is not a big issue here, note that Windows generally searches for DLLs in the known/expected places _before_ checking to see if it's in the current working directory.  This prevents a sneaky download from effectively replacing a DLL.  Replacing a PDB is probably less of a concern.</div><div><a href="https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications" target="_blank">https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications</a></div></blockquote><div><br></div><div>This is about the runtime dynamic module loader, not the debugger.</div><div><br></div><div><br><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 1:28 PM Adrian McCarthy <<a href="mailto:amccarth@google.com" target="_blank">amccarth@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">It's really frustrating how the email discussion doesn't always make it to Phabricator.<div><br></div><div>The Windowsy thing to do is what Zach said:  Check the directory that contains the .dmp for the .pdb.  It's the first place the VS debugger looks when opening a minidump.  It's less sensitive to the user's environment.  (Making the user change the current working directory for this could be at odds with other bits of the software that look relative the cwd.)</div><div><br></div><div><a href="https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Find_binaries__symbol___pdb__files__and_source_files" target="_blank">https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Find_binaries__symbol___pdb__files__and_source_files</a><br></div><div><br></div><div>While security is not a big issue here, note that Windows generally searches for DLLs in the known/expected places _before_ checking to see if it's in the current working directory.  This prevents a sneaky download from effectively replacing a DLL.  Replacing a PDB is probably less of a concern.</div><div><br></div><div><a href="https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications" target="_blank">https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications</a><br></div><div><br></div><div>So I +1 Zach's proposal.</div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 12:07 PM Leonard Mosescu <<a href="mailto:mosescu@google.com" target="_blank">mosescu@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I think as combination of explicit symbol search path + something similar to Microsoft's symsrv would be a good "real" solution (and yes, that would be packaged as a SymbolVendor, outside SymbolFilePDB)<div><br></div><div>For short term, I don't see a clearly superior alternative to searching the current directory.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 12:02 PM Pavel Labath <<a href="mailto:pavel@labath.sk" target="_blank">pavel@labath.sk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/12/2018 20:34, Zachary Turner wrote:<br>
> I meant the location of the minidump.  So if you have C:\A\B\C\foo.dmp <br>
> which is the dump file for bar.exe which crashed on another machine, <br>
> then it would look for C:\A\B\C\bar.pdb.  That actually seems like <br>
> fairly intuitive behavior to me, but maybe I'm in the minority :)<br>
> <br>
> We can see what Pavel, Adrian, and others think though or if they have <br>
> any other suggestions.<br>
> <br>
<br>
It sounds like there is a precedent for searching in CWD. I don't know <br>
how useful it is (I traced it back to r185366, but it is not mentioned <br>
there specifically), but it is there, and I guess it's not completely <br>
nonsensical from the POV of a command line user.<br>
<br>
I guess we can just keep that there and not call it a hack (though, the <br>
fact that the searching happens inside SymbolFilePDB *is* a hack).<br>
<br>
Searching in the minidump directory would also make sense somewhat, but <br>
I expect you would need more plumbing for that to happen (and I don't <br>
know of a precedent for that).<br>
<br>
pl<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>