From 7947f35071e8d87bbe77f13d9c0b106c16facaf1 Mon Sep 17 00:00:00 2001 From: Ella Hathaway Date: Mon, 1 Dec 2025 17:26:06 +0000 Subject: [PATCH] Patch CoreCLR failure fix --- ...ing-Add-flags-when-the-clang-s-major.patch | 145 ++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 src/SourceBuild/patches/runtime/0001-release-9.0-staging-Add-flags-when-the-clang-s-major.patch diff --git a/src/SourceBuild/patches/runtime/0001-release-9.0-staging-Add-flags-when-the-clang-s-major.patch b/src/SourceBuild/patches/runtime/0001-release-9.0-staging-Add-flags-when-the-clang-s-major.patch new file mode 100644 index 000000000000..395dea35c1ae --- /dev/null +++ b/src/SourceBuild/patches/runtime/0001-release-9.0-staging-Add-flags-when-the-clang-s-major.patch @@ -0,0 +1,145 @@ +From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 +From: Aaron R Robinson +Date: Fri, 14 Nov 2025 11:01:28 -0800 +Subject: [PATCH] [release/9.0-staging] Add flags when the clang's major + version is > 20.0 (#121151) +Backport: https://github.com/dotnet/runtime/pull/121151 + +## Customer Impact + +- [x] Customer reported +- [ ] Found internally + +These issues were reported in +https://github.com/dotnet/runtime/issues/119706 as problems with +clang-21 on Fedora 43. The investigation uncovered that clang introduced +a potentially breaking change in clang-20 that we do not currently +consume. These build changes impact VMR related builds when linux +distrobutions performing source build adopt clang-21. + +clang-20 breaking change log - +https://releases.llvm.org/20.1.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes. + +This PR contains the minimal changes needed to fix issues from the +following PR https://github.com/dotnet/runtime/pull/120775. + +.NET 10: https://github.com/dotnet/runtime/pull/121124 +.NET 8: https://github.com/dotnet/runtime/pull/121150 + +## Regression + +- [ ] Yes +- [x] No + +Build with the new clang-21 compiler will cause the runtime to crash. + +## Testing + +This has been validated using various legs and examples to demonstrate +the usage of undefined behavior these flags convert into "defined" +behavior in C/C++. + +## Risk + +Low. This has zero impact on our production build since we specifically +target clang-18. This is only valid for those partners that are using +clang-20+. +--- + eng/native/configurecompiler.cmake | 18 +++++++++++++++--- + src/coreclr/debug/di/rspriv.h | 4 ++-- + src/coreclr/debug/di/rsthread.cpp | 12 ++++++------ + 3 files changed, 23 insertions(+), 11 deletions(-) + +diff --git a/eng/native/configurecompiler.cmake b/eng/native/configurecompiler.cmake +index 109b947e4eb..c114c03a9a1 100644 +--- a/eng/native/configurecompiler.cmake ++++ b/eng/native/configurecompiler.cmake +@@ -526,9 +526,21 @@ if (CLR_CMAKE_HOST_UNIX) + # Disable frame pointer optimizations so profilers can get better call stacks + add_compile_options(-fno-omit-frame-pointer) + +- # Make signed arithmetic overflow of addition, subtraction, and multiplication wrap around +- # using twos-complement representation (this is normally undefined according to the C++ spec). +- add_compile_options(-fwrapv) ++ if((CMAKE_C_COMPILER_ID STREQUAL "Clang" AND CMAKE_C_COMPILER_VERSION VERSION_GREATER_EQUAL 20.0) OR ++ (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" AND CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 20.0)) ++ # Make signed overflow well-defined. Implies the following flags in clang-20 and above. ++ # -fwrapv - Make signed arithmetic overflow of addition, subtraction, and multiplication wrap around ++ # using twos-complement representation (this is normally undefined according to the C++ spec). ++ # -fwrapv-pointer - The same as -fwrapv but for pointers. ++ add_compile_options(-fno-strict-overflow) ++ ++ # Suppress C++ strict aliasing rules. This matches our use of MSVC. ++ add_compile_options(-fno-strict-aliasing) ++ else() ++ # Make signed arithmetic overflow of addition, subtraction, and multiplication wrap around ++ # using twos-complement representation (this is normally undefined according to the C++ spec). ++ add_compile_options(-fwrapv) ++ endif() + + if(CLR_CMAKE_HOST_APPLE) + # Clang will by default emit objc_msgSend stubs in Xcode 14, which ld from earlier Xcodes doesn't understand. +diff --git a/src/coreclr/debug/di/rspriv.h b/src/coreclr/debug/di/rspriv.h +index 7e2b49b3170..119ca6f7c08 100644 +--- a/src/coreclr/debug/di/rspriv.h ++++ b/src/coreclr/debug/di/rspriv.h +@@ -6404,8 +6404,8 @@ private: + // Lazily initialized. + EXCEPTION_RECORD * m_pExceptionRecord; + +- static const CorDebugUserState kInvalidUserState = CorDebugUserState(-1); +- CorDebugUserState m_userState; // This is the current state of the ++ static const int kInvalidUserState = -1; ++ int m_userState; // This is the current state of the + // thread, at the time that the + // left side synchronized + +diff --git a/src/coreclr/debug/di/rsthread.cpp b/src/coreclr/debug/di/rsthread.cpp +index cd7f79867a5..8c4f3317eff 100644 +--- a/src/coreclr/debug/di/rsthread.cpp ++++ b/src/coreclr/debug/di/rsthread.cpp +@@ -783,7 +783,7 @@ CorDebugUserState CordbThread::GetUserState() + m_userState = pDAC->GetUserState(m_vmThreadToken); + } + +- return m_userState; ++ return (CorDebugUserState)m_userState; + } + + +@@ -887,7 +887,7 @@ HRESULT CordbThread::CreateStepper(ICorDebugStepper ** ppStepper) + //Returns true if current user state of a thread is USER_WAIT_SLEEP_JOIN + bool CordbThread::IsThreadWaitingOrSleeping() + { +- CorDebugUserState userState = m_userState; ++ int userState = m_userState; + if (userState == kInvalidUserState) + { + //If m_userState is not ready, we'll read from DAC only part of it which +@@ -3721,14 +3721,14 @@ HRESULT CordbUnmanagedThread::SetupFirstChanceHijackForSync() + LOG((LF_CORDB, LL_INFO10000, "CUT::SFCHFS: hijackCtx started as:\n")); + LogContext(GetHijackCtx()); + +- // Save the thread's full context for all platforms except for x86 because we need the ++ // Save the thread's full context for all platforms except for x86 because we need the + // DT_CONTEXT_EXTENDED_REGISTERS to avoid getting incomplete information and corrupt the thread context + DT_CONTEXT context; +-#ifdef TARGET_X86 ++#ifdef TARGET_X86 + context.ContextFlags = DT_CONTEXT_FULL | DT_CONTEXT_EXTENDED_REGISTERS; + #else + context.ContextFlags = DT_CONTEXT_FULL; +-#endif ++#endif + + BOOL succ = DbiGetThreadContext(m_handle, &context); + _ASSERTE(succ); +@@ -3739,7 +3739,7 @@ HRESULT CordbUnmanagedThread::SetupFirstChanceHijackForSync() + LOG((LF_CORDB, LL_ERROR, "CUT::SFCHFS: DbiGetThreadContext error=0x%x\n", error)); + } + +-#ifdef TARGET_X86 ++#ifdef TARGET_X86 + GetHijackCtx()->ContextFlags = DT_CONTEXT_FULL | DT_CONTEXT_EXTENDED_REGISTERS; + #else + GetHijackCtx()->ContextFlags = DT_CONTEXT_FULL;