> > 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.) > > https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Find_binaries__symbol___pdb__files__and_source_files >
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) 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. > > https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications > This is about the runtime dynamic module loader, not the debugger. On Tue, Dec 11, 2018 at 1:28 PM Adrian McCarthy <amcca...@google.com> wrote: > It's really frustrating how the email discussion doesn't always make it to > Phabricator. > > 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.) > > > https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Find_binaries__symbol___pdb__files__and_source_files > > 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. > > > https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications > > So I +1 Zach's proposal. > > On Tue, Dec 11, 2018 at 12:07 PM Leonard Mosescu <mose...@google.com> > wrote: > >> 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) >> >> For short term, I don't see a clearly superior alternative to searching >> the current directory. >> >> On Tue, Dec 11, 2018 at 12:02 PM Pavel Labath <pa...@labath.sk> wrote: >> >>> On 11/12/2018 20:34, Zachary Turner wrote: >>> > 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. >>> > >>> >>> It sounds like there is a precedent for searching in CWD. I don't know >>> how useful it is (I traced it back to r185366, but it is not mentioned >>> there specifically), but it is there, and I guess it's not completely >>> nonsensical from the POV of a command line user. >>> >>> I guess we can just keep that there and not call it a hack (though, the >>> fact that the searching happens inside SymbolFilePDB *is* a hack). >>> >>> Searching in the minidump directory would also make sense somewhat, but >>> I expect you would need more plumbing for that to happen (and I don't >>> know of a precedent for that). >>> >>> pl >>> >>
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
