Fix Mono Windows x64 crash blocking CI Windows x64 Release job. #46573
Conversation
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
After upgrade to later msvc version on CI boots, see dotnet#45524 for details, Window x64 Release builds started to crash on libraries tests. After investigation it turns out that new msvc compiler handles an expression different compared to how it was handled in previous version. After upgrade of msvc, the expression: int _amd64_width_temp = ((guint64)(imm) == (guint64)(int)(guint64)(imm)); implemented in amd64_mov_reg_imm and then called from tramp-amd64.c@500 was transformed into an always true expression by compiler: amd64_mov_reg_imm (code, AMD64_R11, (guint8*)mono_get_rethrow_preserve_exception_addr ()); lea rcx,[rethrow_preserve_exception_func (07FFB9E33A590h)] mov word ptr [rbx+0Dh],0BB41h mov byte ptr [rbx+0Fh],cl mov rax,rcx shr eax,8 mov byte ptr [rbx+10h],al mov rax,rcx shr eax,10h shr ecx,18h mov byte ptr [rbx+11h],al lea rax,[rbx+13h] mov byte ptr [rbx+12h],cl as seen above, the condition and handling of a 64-bit imm has been dropped by compiler. This cause issues when the imm is a 64-bit value since it will always gets truncated into 32-bit imm and in this case it was a pointer to a function within coreclr.dll (mono_get_rethrow_preserve_exception_addr) loaded located at higher address (using more than 32-bit). This is most likely a regression issue in compiler for this specific construction. I tried simpler construction (using same type conversion) on both old and new compiler version and then it makes the right optimization. Fix is to switch to a macro already available in amd64-codegen (amd64_is_imm32) detecting if an imm needs a 32-bit or 64-bit sized value. This will be correctly optimized by new msvc compiler and even if this is a work around for a what seems to be a optimization bug in the compiler, it is still cleaner and better describes the intent than current code. Fix also re-enable Windows x64 Release CI test lane.
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
lambdageek
approved these changes
Jan 10, 2021
|
Looks like this PR raced with adding System.Speech component and tests. Mono won't be able to support System.Speech on Windows due to no COM wrapper support implemented on Mono runtime under netcore. #46828 disables the tests not working under Mono getting Mono Windows x64 lane back to pass. |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
After upgrade to later msvc version (v16.8.0) on CI boots, see #45524 for details, Window x64 Release builds started to crash on libraries tests.
After investigation it turns out that new msvc compiler handles an expression different compared to how it was handled in previous version.
After upgrade of msvc, the expression:
int _amd64_width_temp = ((guint64)(imm) == (guint64)(int)(guint64)(imm));
implemented in amd64_mov_reg_imm and then called from tramp-amd64.c@500 was transformed into an always true expression by compiler:
as seen above, the condition and handling of a 64-bit imm has been dropped by compiler.
This cause issues when the imm is a 64-bit value since it will always gets truncated into 32-bit imm and in this case it was a pointer to a function within coreclr.dll (mono_get_rethrow_preserve_exception_addr) located at higher address (using more than 32-bit).
This is most likely a regression issue in compiler for this specific construction. I tried simpler construction (using same type conversion) on both old and new compiler version and then it makes the right optimization.
Fix is to switch to a macro already available in amd64-codegen (amd64_is_imm32) detecting if an imm needs a 32-bit or 64-bit sized value. This will be correctly optimized by new msvc compiler and even if this is a work around for a what seems to be a optimization bug in the compiler, it is still cleaner and better describes the intent than current code.
Fix also re-enable Windows x64 Release CI test lane.