[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