You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains 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
CoreCLR runtime build using stdcall while Mono uses cdecl (default for c/c++ source files) as default calling convention. If a native runtime function takes a reverse pinvoke managed callback, this difference will cause issues on Mono Windows x86 since reverse pinvoke callbacks uses stdcall on Windows x86, but native functions calling callbacks have been prototyped to use the "default" calling convention used by native runtime build.
Since CoreCLR already uses stdcall on Windows x86 this change won't change anything on CoreCLR.
On Windows x64 stdcall == cdecl so this change won't change anything on CoreCLR, Mono or NativeAOT.
PR also re-enable test suites previously disabled due to this issue as well as making sure native EventPipe tests suites build/run/ pass using Mono Windows x86.
…dows x86.
CoreCLR runtime get build using stdcall while Mono uses cdecl (default).
If a native runtime function takes a reverse pivnoke callback, this
difference will cause issues for Mono on Windows x86 since reverse
pinvoke callbacks have stdcall on Windows x86, but callbacks have
been prototyped to use the calling convention setup in build.
Since CoreCLR already uses stdcall on Windows x86 this change won't change
anything, while on Mono it will fixes the crashes observed in dotnet#8892.
@davmason, mainly a nop change on all platforms except Mono Windows x86 since CoreCLR Windows x86 already uses stdcall as default calling convention for native code. Would you mind take a look?
Failures in runtime-libraries-mono outerloop (Build windows-x86 Release AllSubsets_Mono) test run after fix and re-enabled tests are not related (failure in System.Numerics.Tests.logTest.RunLargeValueLogTests, and System.Collections.Frozen.Tests.FrozenDictionary_Generic_Tests_ulong_ulong.CreateHugeDictionary_Success), so re-enabled tests seems to have been fixed by changes in this PR.
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.
ghost
locked as resolved and limited conversation to collaborators
Fixes #88992.
CoreCLR runtime build using stdcall while Mono uses cdecl (default for c/c++ source files) as default calling convention. If a native runtime function takes a reverse pinvoke managed callback, this difference will cause issues on Mono Windows x86 since reverse pinvoke callbacks uses stdcall on Windows x86, but native functions calling callbacks have been prototyped to use the "default" calling convention used by native runtime build.
PR also re-enable test suites previously disabled due to this issue as well as making sure native EventPipe tests suites build/run/ pass using Mono Windows x86.