catchsegv not resolving gnu_debuglink correctly #65
Comments
|
It shouldn't be difficult to reproduce this, but it would help me to understand where exactly are the binaries. For example, what's the |
|
Nevermind, I downloaded krita from https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ so I can see all binaries. However I can't reproduce this. It might be something more subtle going on here. Please double check this happens with the released |
|
@alvinhochun, please rerun I want to see what's logged on https://github.com/jrfonseca/drmingw/blob/0.9.5/src/common/debugger.cpp#L676-L698 My guess is that One potential problem is my abuse of |
|
Sorry, I see you already run with the expectation would be so this is consistent with |
If GetFinalPathNameByHandle fails for reasons other than buffer too small, the return value is zero, which wasn't being handled properly. This explains the bogus ImageName seen on #65 However it's not clear what's the cause for GetFinalPathNameByHandle, or what can be done about it.
|
@alvinhochun , ignore all my previous rambles. I think I nailed it in af8adbf. Let me know if the issue persists. |
|
Ah, thanks for looking into this. I always forgot to mention that I am using a ramdisk drive created with ImDisk, which often seems to expose some edge cases in applications. In my case it is still failing to load. A snippet of the debug output: And a snippet of the I think in the case of the path format like |
Yep, I'll push a fix after cleaning up the code somewhat. |
|
Yay it works! 😄 |
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 * jrfonseca/drmingw#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
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 * jrfonseca/drmingw#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
Filing a new issue from #64 (comment)
The
ImageNameargument seems wrong? You can also see thatdrmingw/src/mgwhelp/dwarf_pe.cpp
Line 249 in c03af4c
The text was updated successfully, but these errors were encountered: