llvm-project.git/lldb/source/Plugins/Process/Windows/Common/DebuggerThread.cpp, branch main

fix: Target Process may crash or freezes on detaching process on windows (#115712)

2024-11-15T09:52:36+00:00

Fixes #67825 Fixes #89077

Fixes
[RIDER-99436](https://youtrack.jetbrains.com/issue/RIDER-99436/Unity-Editor-will-be-crashed-when-detaching-LLDB-debugger-in-Rider),
which is upstream issue of #67825.

This PR changes the timing of calling `DebugActiveProcessStop` to after
calling `ContinueDebugEvent` for last debugger exception.

I confirmed the crashing behavior is because we call
`DebugActiveProcessStop` before `ContinueDebugEvent` for last debugger
exception with https://github.com/anatawa12/debug-api-test.

[lldb] Don't flush llvm::raw_string_ostream (NFC) (#110128)

2024-09-26T16:29:14+00:00

Don't call raw_string_ostream::flush(), which is essentially a no-op. As
specified in the docs, raw_string_ostream is always unbuffered. (
65b13610a5226b84889b923bae884ba395ad084d for further reference )

[lldb] Convert DebuggerThread.cpp to new Status API (NFC)

2024-09-06T01:00:53+00:00

[lldb] Convert ProcessWindows.cpp to new Status API (NFC)

2024-09-05T23:12:17+00:00

[lldb] Adapt Plugins/Process/Windows to new Status API

2024-08-28T00:02:49+00:00

[lldb] Use StringRef::{starts,ends}_with (NFC)

2023-12-16T23:02:15+00:00

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

[lldb] Use std::optional instead of llvm::Optional (NFC)

2023-01-07T22:18:35+00:00

This patch replaces (llvm::|)Optional< with std::optional<.  I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/ADT/Optional.h", etc.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

[lldb] Add #include (NFC)

2023-01-07T21:43:00+00:00

This patch adds #include  to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

[lldb] Use std::nullopt instead of llvm::None (NFC)

2022-12-06T07:18:15+00:00

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

[lldb] Fix loading DLL from some ramdisk on Windows

2022-06-15T14:02:33+00:00

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