Fix JIT_CheckedWriteBarrier for MHR (dotnet/coreclr#26430)

When Mojave hardened runtime support is enabled, the runtime places the
JIT_WriteBarrier copy into a dynamically allocated memory page. But
the JIT_CheckedWriteBarrier has a relative jump to the JIT_WriteBarrier
that I've missed when adding the MHR support and so we end up calling
the original unpatched code of the JIT_WriteBarrier from it.
This repros in release build only and causes problems only rarely,
so it was not detected until the corefx was updated to use the latest
coreclr. Even in the corefx tests, it caused problems when compiling
only one of the corefx tests.

This change fixes it in the same way as we handle jump to JIT_WriteBarrier
in the JIT_Stelem_Ref and its helpers - by using an indirect jump.
We do this for OSX only.

Commit migrated from https://github.com/dotnet/coreclr/commit/5b036452e3ed5d8b60435e3423e4fec245827ce1

diff --git a/src/coreclr/src/vm/amd64/jithelpers_fast.S b/src/coreclr/src/vm/amd64/jithelpers_fast.S
index 4e31a60..b81ee37 100644 (file)
--- a/src/coreclr/src/vm/amd64/jithelpers_fast.S
+++ b/src/coreclr/src/vm/amd64/jithelpers_fast.S
@@ -37,11 +37,17 @@ LEAF_ENTRY JIT_CheckedWriteBarrier, _TEXT
         .byte 0x72, 0x0e
         PREPARE_EXTERNAL_VAR g_highest_address, rax
         cmp     rdi, [rax]
+
+#ifdef FEATURE_WRITEBARRIER_COPY
+        // jnb     NotInHeap
+        .byte 0x73, 0x06
+        jmp     [rip + C_FUNC(JIT_WriteBarrier_Loc)]
+#else
         // jnb     NotInHeap
         .byte 0x73, 0x02
-        
-        // call C_FUNC(JIT_WriteBarrier)
+        // jmp C_FUNC(JIT_WriteBarrier)
         .byte 0xeb, 0x05
+#endif
 
     NotInHeap:
         // See comment above about possible AV