Getting Darling To Build On An ARM64 Device #642
Comments
|
It didn't take too long for a build error to occur. The weird this is that this error is not caused by Darling's code, but rather the header files. This error comes from Here is the full log: make_log.txt Edit: I figure out the problem, it has to do with the It makes sense why this would fail (since I don't have the 32bit libraries installed). Seems like disabling Edit2: I added an if condition to build the 32bit version if |
|
The next road blocker I am running into is Going off of this useful link, adding The weird thing about this issue is that it does not occur in the original project (at least from my very basic compile test).
Edit: No, updating it doesn't fix the issue. It has to do with the fact that |
|
What is I noticed that some of the files in that folder are similar to cctools-port:cctools/include/foreign. The boolean.h file in the darling repo doesn't include the other architectures that are found in the cctools-port boolean.h file. Are the files in the |
|
You might also need to update https://github.com/darlinghq/darling/tree/master/src/kernel/libsyscall/bsdsyscalls for ARM64, (currently the macros only check for i386 or x86_64). |
|
@TheBrokenRail I am actually going through that currently. Right now I am just copying and pasting Apple's xnu code in there, but it looks like I am going to have to make some manual changes as well. |
|
Will your work support ARM32, then Darling will work on older Raspberry Pis/rooted Android devices as well! |
|
@TheBrokenRail Not in it's current form. I probably won't support it until I merge ARM64 support into darling and move to a distro that also supports ARM32 (Manjaro ARM only supports ARM64). For now, I want to keep things simple. |
|
Any updates on this? |
|
@TheBrokenRail I have been busy with some IRL stuff (working hard to get my entry level career job!), so I haven't had a lot of time to work on this. IRL stuff aside, I am waiting for @LubosD to update Darling to use the new |
|
@CuriousTommy Done. I happened to do just that because I'm trying to update |
|
Hope to get an update on this. |
Right now I’m trying to update Apple’s source code to their newer version (some of the newer code contain better support for ARM64). This needs to be completed before I can continue my work on building Daring on ARM64 devices. You can see my progress on the Edit: |
|
any update on this , i'm just curious on this initiative , i have Ubuntu touch arm64 and maybe it will run on this if arm64 build will be success , |
Generally speaking, the situation is the same as before. The As for the current status on |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
I guess I should have investigated a bit before spending my morning setting up arm64 Ubuntu in a VM on my Apple Silicon machine... However, this is a very interesting project, and being able to build and run darling on arm64 is very desirable. Are there any major hurdles standing in the way of supporting arm64? I'm more than happy to help in any way I can. |
The situation is mostly the same as what I document above. The sources need to updated before I can continue my work on ARM64 support. Beside getting the sources updated (you can see my progress here), I am running into issues where I can't get JavaScriptCore and Heimdal to build.
If you are interested in looking into getting JavaScriptCore and Heimdal to build with the new source changes, I can provide more details in #1173. You will need to do this on a x86_64 device (or use a translation layer). Be warned through, this stuff is very involved. |
Darlingserver Issues Notes
|
|
I would like to try crosscompilation for AArch64 based nVIDIA Jetson devices. Any initial pointer will be appreciated. Thank you beforehand. |
|
It will be a while before you can build Darling for an ARM64 device. I still need to fix the source code. |
MLDR Issues NotesMissing implementation of
|
I got a question, since this is AT&T syntax, isn't the operand order reversed? Wouldn't it be: rdi = args.pth; // MARK: redundant?
rsp = args.stack_addr;
rsi = args._backwards_compat;
rdx = args.real_entry_point;
if (rdx == NULL) {
rdx = args.real_entry_point;
}
rcx = args.arg1;
r8 = args.arg2;
r9 = args.arg3;
args.pth = rdi; // MARK: redundant cuz of first line?
rax = args->entry_point;
rsp -= 16 // 0x10
push(0);
push(0);
jump_without_return(rax);ARM equivalent (chatgpt made, but hand optimized 🙂): __asm__ __volatile__ (
"mov x0, %1\n"
"ldr x2, [%0, #80]\n"
"ldr x3, [%0, #40]\n"
"ldr x4, [%0, #8]\n"
"cbnz x4, 1f\n"
"ldr x4, [%0, #72]\n" // wqthread hack: if 3rd arg is null, we pass the stack bottom
"1:\n"
"ldr x5, [%0, #16]\n"
"ldr x6, [%0, #24]\n"
"ldr x7, [%0, #32]\n"
"str x0, [%0, #56]\n"
"ldr x8, [%0]\n"
"and sp, sp, #-0x10\n"
"stp xzr, xzr, [sp, #-16]!\n"
"br x8\n"
:: "a" (&args), "r" (args.pth)
: "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7", "x8", "cc", "memory"
); |
You're right. I forgot that there was more than one way for representing x86_64 assembly.
I actually got this part wrong, it's suppose to be
I didn't expect anyone to provide me an ARM64 translation, thanks! One thing I'm going to change is how the values are assigned to the registers. I'm not a huge fan of doing |
|
The idea here is to do as much as possible in C, since that's portable (can be shared among architectures) and easier to understand, and you also don't have to hardcode things like fields offsets. For x86_64, GCC (and Clang) provide constraints, where you can tell it to place an input (or output, but in this case we've got none) into a specific register (or class of registers), like this: // wqthread hack: if 3rd arg is null, we pass the stack bottom
long arg3 = args->arg3;
if (arg3 == 0) {
arg3 = (long) args->stack_bottom;
}
// Make super sure the stack pointer is 16-aligned.
void *stack_ptr = align_16(args->stack_ptr);
asm volatile(
// Zero out the frame base register.
"xorq %%rbp, %%rbp\n"
// Switch to the new stack.
"movq %[stack_ptr], %%rsp\n"
// Push a fake return address.
"pushq $0\n"
// Jump to the entry point.
"jmp *%[jump_here]" ::
"D"(args->arg1), // "D" means %rdi
"S"(args->arg2), // "S" means %rsi
"d"(arg3), // "d" means %rdx
// "r" means any general-purpose register;
// we also give it a name "jump_here" that
// we'll be able to use inside the asm to
// refer to it, instead of %0
[jump_here] "r"(args->jump_here),
// Same for the stack pointer.
[stack_ptr] "r"(stack_ptr)
);
// The above never returns, let the compiler know that.
__builtin_unreachable();(on Godbolt). For aarch64, specific register constraints are not available, and instead you're supposed to use explicit register local variables: register long arg1 asm("x0") = args->arg1;
register long arg2 asm("x1") = args->arg2;
register long arg3 asm("x2") = args->arg3;
// wqthread hack: if 3rd arg is null, we pass the stack bottom
if (arg3 == 0) {
arg3 = (long) args->stack_bottom;
}
// Make super sure the stack pointer is 16-aligned.
void *stack_ptr = align_16(args->stack_ptr);
asm volatile(
// Switch to the new stack.
"mov sp, %[stack_ptr]\n"
// Store a fake zero frame.
"stp xzr, xzr, [sp, #-16]!\n"
// Jump to the entry point.
"br %[jump_here]" ::
"r"(arg1),
"r"(arg2),
"r"(arg3),
[jump_here] "r"(args->jump_here),
[stack_ptr] "r"(stack_ptr)
);
// The above never returns, let the compiler know that.
__builtin_unreachable();(on Godbolt). Wait, but aren't
Even on x86_64, not all registers have corresponding constraints, so you have to resort to explicit register variables if you want to place your variable into r8 or some such. Disclaimer: I'm not as comfortable with arm/aarch64 assembly, I could have messed something up here. I'm only showing a few args, your real version has more things. Also note that there should be no need to clobber anything since we're never returning from the inline asm. (And a nitpick: Bugaev, my last name, is of course capitalized, but bugaevc, my display name, is all lowercase.) |
I'm not that great at inline x86 asm tbh. Got a question though, what's the difference between |
@bugaevc By the way, AARCH64 passes the new frame entirely within registers, so to create a null frame for the function we're jumping to, you would zero-out the frame pointer ( asm volatile(
// Switch to the new stack.
"mov sp, %[stack_ptr]\n"
// Set up a fake zero frame by zeroing the frame pointer and link register
"mov x29, xzr\n"
"mov x30, xzr\n"
// Jump to the entry point.
"br %[jump_here]" ::
"r"(arg1),
"r"(arg2),
"r"(arg3),
[jump_here] "r"(args->jump_here),
[stack_ptr] "r"(stack_ptr)
);
@johnothwolo |
Riggght, because the stack needs to be 16 byte aligned! |
|
I'll need to create an ARM64 equivalent of the
; typedef void* marg_list;
; void __invoke__(
; void (*msgSend)(...), // rdi
; void *retdata, // rsi
; marg_list args, // rdx
; size_t frame_length, // ecx
; const char *return_type // r8
; )
; Make new call frame
push %rbp
movq %rsp, %rbp
; Push following values to stack
push %rdi ; void (*msgSend)(...)
push %rsi ; void *retdata
push %r8 ; const char *return_type
; rsi = rdx (args)
movq %rdx, %rsi
; Push stack down and align
subq %rcx, %rsp ; rsp -= frame_length
andq $-16, %rsp ; rsp &= -16
; Shift stack contents (frame_length/8) times, 8 bytes at a time
; TODO: More efficient than the Lpush loop in i386 assembly above
movq %rsp, %rdi ; rdi = rsp (stack pointer)
shrq $3, %rcx ; frame_length = frame_length >> 3 (frame_length / 8)
cld ; Clear direction flag (Incrementing the pointer to the data
; after every iteration | See https://stackoverflow.com/a/9636772/5988706)
rep movsq ; Move RCX (frame_length) quadwords (8 bytes) from RSI (args) to RDI (stack pointer).
; Copy args into registers
; (Why do we grab the values in this order)?
movq 0xb0(%rsp), %rax ; rax = rsp[0xb0]
movapd 0xa0(%rsp), %xmm7 ; xmm7 = rsp[0xa0]
movapd 0x90(%rsp), %xmm6 ; xmm6 = rsp[0x90]
movapd 0x80(%rsp), %xmm5 ; xmm5 = rsp[0x80]
movapd 0x70(%rsp), %xmm4 ; xmm4 = rsp[0x70]
movapd 0x60(%rsp), %xmm3 ; xmm3 = rsp[0x60]
movapd 0x50(%rsp), %xmm2 ; xmm2 = rsp[0x50]
movapd 0x40(%rsp), %xmm1 ; xmm1 = rsp[0x40]
movapd 0x30(%rsp), %xmm0 ; xmm0 = rsp[0x30]
movq 0x28(%rsp), %r9 ; r9 = rsp[0x28]
movq 0x20(%rsp), %r8 ; r8 = rsp[0x20]
movq 0x18(%rsp), %rcx ; rcx = rsp[0x18]
movq 0x10(%rsp), %rdx ; rdx = rsp[0x10]
movq 8(%rsp), %rsi ; rsi = rsp[0x08]
movq (%rsp), %rdi ; rdi = rsp[0x00]
addq $224, %rsp ; rsp += 224 (We restore the stack?)
movq -8(%rbp), %r10 ; r10 = objc_msgSend
callq *%r10 ; call objc_msgSend
; Grab retdata and return_type
movq -16(%rbp), %rsi ; rsi = retdata
movq -24(%rbp), %rcx ; rcx = return_type
; cl is the lower 8 bits to rcx
; 0x44 is 'D' in ASCII
cmpb $0x44, %cl ; if (returnType[0] == 'D') // long double
je Llongdoubleret. ; goto Llongdoubleret
; Store the return double value into `retdata` array
movapd %xmm1, 32(%rsi)
movapd %xmm0, 16(%rsi)
; Store the return int128 value into `retdata` array
movq %rdx, 8(%rsi)
movq %rax, (%rsi)
; goto Ldone
jmp Ldone
Llongdoubleret:
; Store the return long double value into `retdata` array
fstpt (%rsi)
Ldone:
; restore old call frame
movq %rbp, %rsp
pop %rbp
; Return
retTracing the method calls
Using test class: // This debug method is added to `NSMethodSignature.m`
- (void) darlingDebugPrinting {
printf("{\n");
for (NSUInteger i = 0; i < _count; i++) {
printf("\t{ ");
printf("_types[%lu].size: %lu, ", (unsigned long)i, _types[i].size);
printf("_types[%lu].alignment: %lu, ", (unsigned long)i, _types[i].alignment);
printf("_types[%lu].offset: %zu, ", (unsigned long)i, _types[i].offset);
printf("_types[%lu].type: \"%s\" ", (unsigned long)i, _types[i].type);
printf("}\n");
}
printf("};\n");
}To get a better understanding on what the argument's value should be for For example, if you run |
|
I'll need to convert the following
;/**************************************
; * The marg_list's layout is:
; * d0 <-- args
; * d1
; * d2 | increasing address
; * d3 v
; * d4
; * d5
; * d6
; * d7
; * a1
; * a2
; * a3
; * a4
; * stack args...
; *
; * typedef struct objc_sendv_margs {
; * int a[4];
; * int stackArgs[...];
; * };
; *
; **************************************/
;
; __CF_forwarding_prep_0
; __CF_forwarding_prep_1
;
.section __TEXT,__text,regular,pure_instructions
.globl __CF_forwarding_prep_0
.globl __CF_forwarding_prep_1
.align 4, 0x90
__CF_forwarding_prep_0:
__CF_forwarding_prep_1:
push %rbp
movq %rsp, %rbp
; Copy args from regs into a stack var
subq $0xd0, %rsp
movq %rax, 0xb0(%rsp)
movapd %xmm7, 0xa0(%rsp)
movapd %xmm6, 0x90(%rsp)
movapd %xmm5, 0x80(%rsp)
movapd %xmm4, 0x70(%rsp)
movapd %xmm3, 0x60(%rsp)
movapd %xmm2, 0x50(%rsp)
movapd %xmm1, 0x40(%rsp)
movapd %xmm0, 0x30(%rsp)
movq %r9, 0x28(%rsp)
movq %r8, 0x20(%rsp)
movq %rcx, 0x18(%rsp)
movq %rdx, 0x10(%rsp)
movq %rsi, 8(%rsp)
movq %rdi, (%rsp)
; rdi (arg1), rsi (arg2)
; id ___forwarding___(struct objc_sendv_margs *args, void *returnStorage)
movq %rsp, %rdi
leaq 0xc0(%rsp), %rsi
call ____forwarding___
; check for forwarding completion
cmpq $0, %rax
jne Lfail
; if it's nil, we're done
; now, load the return value from the on-stack storage
; and jump back to our caller
; here's how we get the return values (see NSInvoke.S)
movq 0xc0(%rsp), %rax
movq 0xc8(%rsp), %rdx
movapd 0xd0(%rsp), %xmm0
movapd 0xe0(%rsp), %xmm1
movq %rbp, %rsp
pop %rbp
ret
Lfail:
; if we got a non-nil value, it's our forwarding targe
movq %rax, %rdi
movq 0x80(%rsp), %rax
movapd 0xa0(%rsp), %xmm7
movapd 0x90(%rsp), %xmm6
movapd 0x80(%rsp), %xmm5
movapd 0x70(%rsp), %xmm4
movapd 0x60(%rsp), %xmm3
movapd 0x50(%rsp), %xmm2
movapd 0x40(%rsp), %xmm1
movapd 0x30(%rsp), %xmm0
movq 0x28(%rsp), %r9
movq 0x20(%rsp), %r8
movq 0x18(%rsp), %rcx
movq 0x10(%rsp), %rdx
movq 8(%rsp), %rsi
; movq (%rsp), %rdi // self overwritten
movq %rbp, %rsp
pop %rbp
; restart message send
jmp _objc_msgSend
;
; __CF_forwarding_prep_b
;
.globl __CF_forwarding_prep_b
.align 4, 0x90
__CF_forwarding_prep_b:
push %rbp
movq %rsp, %rbp
; Copy args from regs into a stack var
subq $0xd0, %rsp
movq %rax, 0xb0(%rsp)
movapd %xmm7, 0xa0(%rsp)
movapd %xmm6, 0x90(%rsp)
movapd %xmm5, 0x80(%rsp)
movapd %xmm4, 0x70(%rsp)
movapd %xmm3, 0x60(%rsp)
movapd %xmm2, 0x50(%rsp)
movapd %xmm1, 0x40(%rsp)
movapd %xmm0, 0x30(%rsp)
movq %r9, 0x28(%rsp)
movq %r8, 0x20(%rsp)
movq %rcx, 0x18(%rsp)
movq %rdx, 0x10(%rsp)
movq %rsi, 8(%rsp)
movq %rdi, (%rsp)
; call into the actual forwarder
; void __block_forwarding__(void* frame)
movq %rsp, %rdi
call ___block_forwarding__
movq %rbp, %rsp
pop %rbp
ret |
|
This is when trying to cmake inside debian arm with UTM, inside Apple silicon: |
|
@superbonaci Weird... I though I fixed that. With that being said, I don't recommend anyone trying to build or use the ARM64 branch for now, it's still very WIP.
|
|
Also the package |
I'm planning to update the build instructions for Fedora to include the dependencies needed for ARM64 (for the other distros, I'll let other people create PRs for the needed ARM64 dependencies). However, I'll only do that after ARM64 support is ready. |
|
possibly relevant currently LINUX_SYSCALL() needs an architecture dependent identifier to find it. Switching to syscall names could make the ARM64 port more future resistant. I would do it myself, but at the current moment I can't even get any code functioning within darwin, so until I've tackled some interim projects I won't be doing this. |
To help me better understand, what do you mean by "architecture dependent identifier"? Are you referring to having macros/const values for the syscall numbers? |
a. You would be totally right to not understand it. I worded it poorly. When I wrote this I was thinking: "If I can make linux syscalls by name in c code; the LINUX_SYSCALL() macro, can too. A hidden assumption I was making was that since I could access any syscall from my c code by name I could access them all by name from my c code. Lately I've been getting doubt about this mostly in a "if I can think of it other smarter people could have thought of it too" way. If I'm right nobody working on the darling project needs to be looking up Linux syscall numbers, because the writers of our compilers, libraries and kernels already have. |
I understand that ARM64 support isn't a high priority for Darling, but there are some parts that I probably would not understand or know how to resolve on my own. I am hoping the Darling team would be able to help me or push me at the right direction.
So I recently got a Pinebook Pro and installed Manjaro ARM on it. Majority of the packages needed are available, with the exception of
gcc-multilibandlib32-gcc-libs. As a result, I have disabledTARGET_i386. I should include a proper build target for ARM64, but for the time being, I want to see how far I can get away with usingTARGET_x86_64.Any issues I have with ARM64 will be posted here (to avoid clutter since ARM64 isn't an officially supported platform). I also included some cmake logs if you need to take a look at the logs.
cmake_log.txt
CMakeError.log
CMakeOutput.log
The text was updated successfully, but these errors were encountered: