Actually, Adrian just tested this on his machine and it did look in his
minidump folder. I don't know why we're seeing different behavior. Either
way, regardless of whether MSVC / WinDbg look in the minidump folder, I
still think it's a pretty intuitive location to add in the default search
path. But if people disagree, it seems like target symbols add would still
address the problem in a permanent way.
On Tue, Dec 11, 2018 at 3:04 PM Zachary Turner <ztur...@google.com> wrote:
> Only one way to know for sure, and that's to test it :) So I did.
>
> 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:
>
> ```
> if (ExeLocation = FindExecutableInMinidumpFolder()) {
> PdbLocation = FindPdbFromExecutable(ExeLocation)
> } else {
> PdbLocation = FindPdbInMinidumpFolder();
> if (!PdbLocation)
> PdbLocation = FindPdbInSympath();
> }
> ```
>
> and that would be pretty logical and not code that we would have to
> consider temporary.
>
> 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.
>
> 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.
>
> On Tue, Dec 11, 2018 at 2:17 PM Adrian McCarthy <amcca...@google.com>
> wrote:
>
>> 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.
>>
>> 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.
>>
>> On Tue, Dec 11, 2018 at 2:12 PM Leonard Mosescu <mose...@google.com>
>> wrote:
>>
>>> 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
