[mono][interp] Always sign extend small integers to native integer when returning to compiled code #117336
Conversation
This file contains hidden or 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
BrzVlad
requested review from
kotlarmilos,
steveisok and
vitek-karas
as code owners
|
Tagging subscribers to this area: @BrzVlad, @kotlarmilos |
There was a problem hiding this comment.
Pull Request Overview
This PR ensures small integer return values are always sign-extended to the native register size on 64-bit platforms by introducing a specialized conversion function and updating return-value marshaling.
- Adds
stackval_to_data_sign_extto handle sign-/zero-extension for 8-, 16-, and 32-bit return types on 64-bit targets. - Replaces calls to
stackval_to_datawithstackval_to_data_sign_extininterp_frame_arg_to_dataandinterp_entry.
Comments suppressed due to low confidence (1)
src/mono/mono/mini/interp/interp.c:988
- No tests currently verify that small-integer return values are correctly sign-/zero-extended. Consider adding interpreter unit tests that exercise methods returning i1, u1, i2, u2, i4, and u4 on 64-bit platforms to catch any regression.
static void
This was referenced Jul 6, 2025
kotlarmilos
approved these changes
Jul 7, 2025
…en returning to compiled code On amd64 it seems our jit expects i4 to be sign extended to the full 64bit register. On arm64 apple, unlike arm64 linux, callers of methods returning i1,u1,i2 or u2 are expecting a value sign extended to i4. In order to prevent any potential issues around this area, this commit takes on a conservative approach and sign extends every time, since there is no real cost to it. stackval_to_data_sign_ext is called either with a data pointer from a CallContext register or the address of a native int local variable in the `mini_get_interp_in_wrapper`. This means that it should always be safe to write the full value.
BrzVlad
force-pushed
the
fix-interp-sign-ext
branch
from
b9ea796 to
5334107
Compare
BrzVlad
force-pushed
the
fix-interp-sign-ext
branch
from
7686515 to
eb3319b
Compare
Those wrappers use the real type as the return, so sign extension shouldn't be needed and it wouldn't be safe, because the wrapper passes the address of the return var of the actual type. Attemptying to sign extend could overflow the storage of this var.
BrzVlad
force-pushed
the
fix-interp-sign-ext
branch
from
ef0505f to
4bb2c5e
Compare
|
backport to release/9.0? |
|
The bug is not critical enough to backport so late in the release cycle. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
On amd64 it seems our jit expects i4 return to be sign extended to the full 64bit register. On arm64 apple, unlike arm64 linux, callers of methods returning i1,u1,i2 or u2 are expecting a value sign extended to i4. In order to prevent any potential issues around this area, this commit takes on a conservative approach and sign extends every time, since there is no real cost to it.
stackval_to_data_sign_ext is called either with a data pointer from a CallContext register or the address of a native int local variable in the
mini_get_interp_in_wrapper. This means that it should always be safe to write the full value.Fixes #115859
Fixes #110649
More general alternative to #117306