[CoreCLR] Avoid having any internal calls in managed code for CoreCLR. Fixes #15343. #15358
Conversation
Fixes dotnet#15343. CoreCLR does not like running into methods declared as internal calls: [MethodImplAttribute (MethodImplOptions.InternalCall)] and will fail with an error, even if the method is never executed, just encountered by the JIT: ECall methods must be packaged into a system module In the early days of .NET support we solved this by adding an indirection for CoreCLR, where the internal call was hidden inside a managed call that would never be executed at runtime. This seems to work fine in most cases, except when the debugger attached, when I'm guessing the JIT is more aggressive, and looks further ahead (and fails). On the other hand, in the early days of .NET support on macOS the managed code had to work for both Mono and CoreCLR without modification (since the same implementation assembly would be picked by the build independent on the actual runtime). This is no longer the case, since we only support CoreCLR on macOS now, which allows us to put any Mono-specific managed code (such as the internal call) in !macOS conditions. Fixes dotnet#15343.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
🔥 [PR Build] Build failed 🔥Build failed for the job 'Detect API changes' Pipeline on Agent |
|
🔥 Unable to find the contents for the comment: D:\a\1\s\change-detection\results\gh-comment.md does not exist :fire Pipeline on Agent |
💻 [PR Build] Tests on macOS Mac Catalina (10.15) passed 💻✅ All tests on macOS Mac Catalina (10.15) passed. Pipeline on Agent |
❌ [PR Build] Tests on macOS M1 - Mac Big Sur (11.5) failed ❌Failed tests are:
Pipeline on Agent |
🔥 [CI Build] Test results 🔥Test results❌ Tests failed on VSTS: simulator tests 0 tests crashed, 5 tests failed, 218 tests passed. Failures❌ introspection tests
Html Report (VSDrops) Download ❌ monotouch tests
Html Report (VSDrops) Download ❌ mtouch tests
Html Report (VSDrops) Download Successes✅ bcl: All 69 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
|
Test failures are unrelated (#15422, #15423 and https://github.com/xamarin/maccore/issues/2597) |
|
/sudo backport release/6.0.3xx |
|
/sudo backport release/6.0.4xx |
|
Backport Job to branch release/6.0.3xx Created! The magic is happening here |
|
Backport Job to branch release/6.0.4xx Created! The magic is happening here |
|
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6396818 for more details. |
|
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6396819 for more details. |
…d code for CoreCLR. Fixes #15343. (#15458) CoreCLR does not like running into methods declared as internal calls: [MethodImplAttribute (MethodImplOptions.InternalCall)] and will fail with an error, even if the method is never executed, just encountered by the JIT: ECall methods must be packaged into a system module In the early days of .NET support we solved this by adding an indirection for CoreCLR, where the internal call was hidden inside a managed call that would never be executed at runtime. This seems to work fine in most cases, except when the debugger attached, when I'm guessing the JIT is more aggressive, and looks further ahead (and fails). On the other hand, in the early days of .NET support on macOS the managed code had to work for both Mono and CoreCLR without modification (since the same implementation assembly would be picked by the build independent on the actual runtime). This is no longer the case, since we only support CoreCLR on macOS now, which allows us to put any Mono-specific managed code (such as the internal call) in !macOS conditions. Fixes #15343. Backport of #15358 Co-authored-by: Rolf Bjarne Kvinge <[email protected]>
CoreCLR does not like running into methods declared as internal calls:
and will fail with an error, even if the method is never executed, just encountered by the JIT:
In the early days of .NET support we solved this by adding an indirection for
CoreCLR, where the internal call was hidden inside a managed call that would
never be executed at runtime. This seems to work fine in most cases, except
when the debugger attached, when I'm guessing the JIT is more aggressive, and
looks further ahead (and fails).
On the other hand, in the early days of .NET support on macOS the managed code
had to work for both Mono and CoreCLR without modification (since the same
implementation assembly would be picked by the build independent on the actual
runtime). This is no longer the case, since we only support CoreCLR on macOS
now, which allows us to put any Mono-specific managed code (such as the
internal call) in !macOS conditions.
Fixes #15343.