-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8262901: [macos_aarch64] NativeCallTest expected:<-3.8194101E18> but was:<3.02668882E10> #6641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
👋 Welcome back KaperD! A progress list of the required criteria for merging this PR into |
Webrevs
|
Thanks for this contribution. Which set of tests have you been using? |
Tier1 and tests from compiler/jvmci/jdk.vm.ci.code.test (maybe they are included to Tier1, but I also run them separately) |
Please add some test with an odd number of arguments. |
Done. I took test I32SDILDS, copied it and change last 6 arguments for 1 int argument, also changed return type to int. |
I don't know why checks were stoped. What can I do to fix it? |
I think that patch is ready to be viewed |
@theRealAph Can you review changes? |
@KaperD This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could someone look at this? The change looks good to me, but I'm not a reviewer. Danil does not have JBS account (yet), so the issue is assigned to me.
Looks OK to me. @dougxc or @tkrodriguez, could you look at this too? |
@KaperD This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 1232 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@AntonKozlov, @dean-long, @dougxc, @theRealAph) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing my review based on input from @teshull. He will leave comments on further changes that are needed.
@@ -265,11 +268,25 @@ private CallingConvention callingConvention(RegisterArray generalParameterRegist | |||
|
|||
if (locations[i] == null) { | |||
ValueKind<?> valueKind = valueKindFactory.getValueKind(kind); | |||
int kindSize = valueKind.getPlatformKind().getSizeInBytes(); | |||
if (macOS && currentStackOffset % kindSize != 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this logic only be included for HotSpotCallingConventionType.NativeCall, but not JavaCall/JavaCallee?
In native-image, the equivalent logic is here: https://github.com/oracle/graal/blob/cf81d2a7c3cbaa2574d0ecbbc2e76879b7719b20/substratevm/src/com.oracle.svm.core.graal.aarch64/src/com/oracle/svm/core/graal/aarch64/SubstrateAArch64RegisterConfig.java#L333
} | ||
} | ||
|
||
if (currentStackOffset % target.stackAlignment != 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this must be taken care of somewhere else. Otherwise, amd64 would also have this same problem, as its stack alignment is also 16 bytes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The SIGBUS issue looks to be more a problem with AArch64TestAssembler.java rather than an issue here. It would be best to align stack size at emitGrowStack(cc.getStackSize()); and emitGrowStack(-cc.getStackSize());
The same thing could be done to AMD64TestAssembler.
At least for graal, this more closely matches the logic of AArchFrameMap and AMD64FrameMap
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Following Doug's lead and removing approval.
@KaperD are you planning to update this PR? |
@KaperD This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
@KaperD This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the |
This is the fix of aarch64 jvmci calling convention.
On MacOS/aarch64 "Function arguments may consume slots on the stack that are not multiples of 8 bytes" [1], but current approach uses only wordsize or bigger slots, which is incorrect (that is why tests were failing [4]). Now arguments consume the right amount of bytes.
Another problem is that current approach don't make 16-byte alignment of Stack Pointer [1][2][3]. However, tests not fail on Linux/aarch64 and Windows/aarch64. They pass because in this tests all functions have even number of argumets, that is why 16-byte alignment comes automatically. But if you try to add or delete one argumets, tests will fail with SIGBUS.
I've tested this patch on MacOS/aarch64 and Linux/aarch64, all tests have passed.
Also I don't understand, why current tests (NativeCallTest) use only int, long, float and double as arguments types. Is it possible to add functions with another types like byte or short? I tried, but it fails on every platform.
[1] https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms
[2] https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#the-stack
[3] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack
[4] https://bugs.openjdk.java.net/browse/JDK-8262901
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6641/head:pull/6641
$ git checkout pull/6641
Update a local copy of the PR:
$ git checkout pull/6641
$ git pull https://git.openjdk.java.net/jdk pull/6641/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 6641
View PR using the GUI difftool:
$ git pr show -t 6641
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6641.diff