-
Notifications
You must be signed in to change notification settings - Fork 2.7k
ARM32: fix interface dispatch cell address transfer #14090
Conversation
wrong disasm:
after fix:
After this change we got a working version for ARM Tizen with RyuJIT and ILC/CoreRT compiler!!! |
@Dmitri-Botcharnikov |
src/jit/lower.cpp
Outdated
@@ -3803,7 +3803,11 @@ GenTree* Lowering::LowerVirtualStubCall(GenTreeCall* call) | |||
// on x64 we must materialize the target using specific registers. | |||
addr->gtRegNum = comp->virtualStubParamInfo->GetReg(); | |||
|
|||
// On ARM we must use a proper address in R12(thunk register) without dereferencing. | |||
// So for the jump we use the default register. | |||
#ifndef _TARGET_ARM_ | |||
indir->gtRegNum = REG_JUMP_THUNK_PARAM; |
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.
Does the register need to be ever fixed for any platform? Should this rather be deleted?
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'll try it on tests.
150a9b4
to
534b508
Compare
What is the requirement here, for CoreRT? I don't think deleting the line is correct. I thought that x64, at least, required the address in a specific register. Does the change need to be specific to CoreRT and not change CoreCLR? If you run diffs for x64, are there any? |
I have updated the CoreRT ABI doc in #14120 with CoreRT details. I do not think any platform requires the target in a specific register. The only requirement is that the indirection that the target was fetched from has to be in a specific register. It is how it is written in https://github.com/dotnet/coreclr/blob/master/Documentation/botr/clr-abi.md at least. My guess is that If there is a worry about regressing x64, I think we can keep the change under ifdef - but it may be nice to add a TODO comment that it is probably unnecessary. |
Would it be obvious, if looking at the VM stub code, whether it uses the stub address as currently set up (for amd64, e.g.)? |
There are 3 different stubs that this can go to. All of them trash https://github.com/dotnet/coreclr/blob/master/src/vm/amd64/virtualcallstubcpu.hpp#L75 |
534b508
to
050fb2a
Compare
@jkotas please review again |
@dotnet-bot test Tizen armel Cross Debug Build please |
@dotnet-bot test Windows_NT arm Cross Checked Build and Test |
Signed-off-by: Petr Bred <bredpetr@gmail.com>
050fb2a
to
74478f4
Compare
@dotnet-bot test Windows_NT arm Cross Checked Build and Test please |
@BruceForstall please review again |
Signed-off-by: Petr Bred bredpetr@gmail.com