release/19.x: [compiler-rt] [fuzzer] Skip trying to set the thread name on MinGW (#115167) #115287
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@devnexen What do you think about merging this PR to the release branch? |
|
@llvm/pr-subscribers-compiler-rt-sanitizer Author: None (llvmbot) ChangesBackport 87f4bc0 Requested by: @mstorsjo Full diff: https://github.com/llvm/llvm-project/pull/115287.diff 1 Files Affected:
diff --git a/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp b/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
index 73eea07cf869ff..da3eb3cfb34063 100644
--- a/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
+++ b/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
@@ -239,10 +239,11 @@ size_t PageSize() {
}
void SetThreadName(std::thread &thread, const std::string &name) {
-#if defined(_LIBCPP_HAS_THREAD_API_PTHREAD) || \
- defined(_GLIBCXX_GCC_GTHR_POSIX_H)
- (void)pthread_setname_np(thread.native_handle(), name.c_str());
-#else
+#ifndef __MINGW32__
+ // Not setting the thread name in MinGW environments. MinGW C++ standard
+ // libraries can either use native Windows threads or pthreads, so we
+ // don't know with certainty what kind of thread handle we're getting
+ // from thread.native_handle() here.
typedef HRESULT(WINAPI * proc)(HANDLE, PCWSTR);
HMODULE kbase = GetModuleHandleA("KernelBase.dll");
proc ThreadNameProc =
|
devnexen
approved these changes
Nov 7, 2024
…lvm#115167) Since b4130be, we check for _LIBCPP_HAS_THREAD_API_PTHREAD to decide between using SetThreadDescription or pthread_setname_np for setting the thread name. c6f3b7b changed how libcxx defines their configuration macros - now they are always defined, but defined to 0 or 1, while they previously were either defined or undefined. As these libcxx defines used to be defined to an empty string (rather than expanding to 1) if enabled, we can't easily produce an expression that works both with older and newer libcxx. Additionally, these defines are libcxx internal config macros that aren't a detail that isn't supported and isn't meant to be relied upon. Simply skip trying to set thread name on MinGW as we can't easily know which kind of thread native handle we have. Setting the thread name is only a nice to have, quality of life improvement - things should work the same even without it. Additionally, libfuzzer isn't generally usable on MinGW targets yet (Clang doesn't include it in the getSupportedSanitizers() method for the MinGW target), so this shouldn't make any difference in practice anyway. (cherry picked from commit 87f4bc0)
|
@mstorsjo (or anyone else). If you would like to add a note about this fix in the release notes (completely optional). Please reply to this comment with a one or two sentence description of the fix. When you are done, please add the release:note label to this PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport 87f4bc0
Requested by: @mstorsjo