ruby: add clangarm64 target #13115
ruby: add clangarm64 target #13115
Conversation
| + frame.AddrPC.Mode = AddrModeFlat; | ||
| + frame.AddrPC.Offset = context.Pc; | ||
| + frame.AddrFrame.Mode = AddrModeFlat; | ||
| + frame.AddrFrame.Offset = context.Fp; | ||
| + frame.AddrStack.Mode = AddrModeFlat; | ||
| + frame.AddrStack.Offset = context.Sp; |
There was a problem hiding this comment.
Got the inspiration for this from https://reviews.llvm.org/D45590
d8e22ea to
879fda7
Compare
|
That code looks at the machine code for These are probably the instructions for arm64 |
|
What tool do you use to get that info? Happy to take a look but I'm really new to this stuff. Am I right in assuming this is mostly a matter of "finding at what address this code is defined" so the compiler can find it? |
|
Closing this as I was able to work around the dependency on Ruby in my project. Unfortunately don't have the bandwidth currently to dive deeper into this |
|
Cool. This code is really gross, but upstream ruby seemed insistent that they really needed that private pointer for something. I used WinDBG to disassemble |
|
The assembly look like this |
|
Yes |
|
Can anyone compile the aarch64 ruby package with the following patch? Just for fun. --- a/win32/win32.c
+++ b/win32/win32.c
@@ -2622,15 +2622,13 @@
}
}
}
- fprintf(stderr, "unexpected " UCRTBASE "\n");
- _exit(1);
found:
p += sizeof(PIOINFO_MARK) - 1;
#ifdef _WIN64
rel = *(int32_t*)(p);
rip = p + sizeof(int32_t);
- __pioinfo = (ioinfo**)(rip + rel);
+ __pioinfo = 0xDEADBEEF;
#else
__pioinfo = *(ioinfo***)(p);
#endif |
|
@Biswa96 that results in When I change it to Here's more logs from the build: build.txt Happy to test further and/or to give you access to an ARM64 VM for further testing. |
|
Opps! I forgot ruby compiles itself first to create miniruby executable. My previous comment is just for having fun with ruby, not so serious. Here was the plan 😈
|
|
@Biswa96 I tried Am I missing something? I'm completely new to this stuff but eager to learn a bit more haha. For reference, I'm on Windows 11 22623.730. UPDATE: I could reproduce this error on a fresh Azure ARM64 VM with 22621.521. Let me know if you want access to that for further debugging. |
|
That offset value (0x1dbdc0) is not constant for every Windows builds. I provided it as an example with WinPE system. It has to be calculated as I have shown. |
|
Gotcha, thanks. I did So that'd get us to Here's the full output of |
|
|
|
Doh! 🤦🏼♂️ My head is in weekend mode haha. Here we go: |
|
Could you give me any pointers (pun intended) as to how I can use this info to get a |
|
I am not familiar with ARM assembly. I just started reading the ARM manual one week ago. Others may provide some hint. IMO, it is not possible to get that offset value of DLLs are different in Windows 10 and 11. e.g. Win11 DLLs have pointer authentication instructions PACIBSP and AUTIBSP. |
|
Let's reopen this PR then so others can chime in 👍🏼 |
I think it is (technically, instruction checking not necessarily byte, on arm64 I think instructions are 4 bytes), with similar limitations/assumptions/brittleness that the x86/x86_64 code has. Let me try describing what it's doing at a higher level, maybe that will help. It scans starting at the address of _isatty looking for the end of the function (a From there, it looks backwards for the last instruction that loads an address (not a very good description), decodes the immediate that says where that address is (on x86_64 that means using the rip-relative offset) to get the pointer. On ARM64, what I would try doing is scanning forward for a |
|
Agree. I also try to follow the x86 way but some variables caught me. Can we be sure that - 1. the operand always will be Speaking of docs, I have read this https://developer.arm.com/documentation/ddi0487/latest. The ARM encoding is fairly interesting to me. For ardp, see C6.2.11 section. |
1 and 3, no, but those same assumptions (that it's the last one, and that it uses the same register) are made in the x86 variants. That's what I was getting at about the brittleness. 2, probably, since they form one logical operation/pseudo-instruction. |
Something like this?
|
|
Since there hasn't been any progress here or upstream (https://bugs.ruby-lang.org/issues/18605) I've created #16135 which just includes the patch. |
This enables the
clangarm64target. The build is currently failing withunexpected ucrtbase.dll. I saw this related issue and would appreciate getting some pointers on how to fix this in a similar way that was done in this PR. Happy to provide an upstream PR once we have this working. CC @jeremyd2019 🙏🏼the error: