[all-commits] [llvm/llvm-project] 87a2db: [lldb] Fix loading DLL from some ramdisk on Windows
alvinhochun via All-commits
all-commits at lists.llvm.org
Wed Jun 15 07:03:07 PDT 2022
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: 87a2dba14ec82629317e13c2bce4c93b4d0a837d
https://github.com/llvm/llvm-project/commit/87a2dba14ec82629317e13c2bce4c93b4d0a837d
Author: Alvin Wong <alvin at alvinhc.com>
Date: 2022-06-15 (Wed, 15 Jun 2022)
Changed paths:
M lldb/source/Plugins/Process/Windows/Common/DebuggerThread.cpp
Log Message:
-----------
[lldb] Fix loading DLL from some ramdisk on Windows
The WinAPI `GetFinalPathNameByHandle` is used to retrieve the DLL file
name from the HANDLE provided to `LOAD_DLL_DEBUG_EVENT` in the debug
loop. When this API fails, lldb will simply ignore that module.
Certain ramdisk (e.g. ImDisk) does not work with this API, which means
it is impossible to use lldb to debug a process which loads DLLs located
on this type of ramdisk. In order to make this work, we need to use a
fallback routine which involves creating a file mapping, using
`GetMappedFileName` to get a device path, then substitutes the device
path with its drive letter.
References:
* https://developercommunity.visualstudio.com/t/cannot-debug-program-when-compiled-to-ram-drive/43004#T-N109926
* https://github.com/jrfonseca/drmingw/issues/65
* https://docs.microsoft.com/en-us/windows/win32/memory/obtaining-a-file-name-from-a-file-handle
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D126657
More information about the All-commits
mailing list