-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
WIP: Add support for arm-linux-musleabihf #5862
Conversation
f770931
to
794525b
Compare
@@ -36,9 +36,11 @@ class Crystal::Program | |||
set.add "x86_64" if set.any?(&.starts_with?("amd64")) | |||
set.add "i686" if set.any? { |flag| %w(i586 i486 i386).includes?(flag) } | |||
|
|||
set.add "musl" if set.includes?("musleabihf") |
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.
you should probably add "gnu" if it includes gnueabihf, just to make this symmetrical. It's not currently used but it may be in the future.
Same as #5861: if you can cross-compile the compiler and run the spec suite sucesfully on the target machine this is good to go. |
I did not yet, it’s in progress. ;) |
It seems that I did something wrong, compiling crystal on armhf with cross-compiled crystal fails:
|
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.
you need to fix
@jirutka can you run in |
(I’m building crystal 0.24.2 with patch for armhf and patch for aarch64 support) |
Hmm, looks like raising/libunwind is different on musl arm. They don't seem to be different on |
To be symetrical with musl. It's not currently used but it may be in the future.
01be976
to
3236720
Compare
I’ve tried to cross-compile for armhf with |
Oh crap, it worked thanks to non-release build, not
Hm, what |
@jirutka yes, it's just compiler optimization. That's strange. Probably a compiler (or llvm) bug. We're still failing to raise/unwind anyway so it hasn't helped much... |
Unwinding is specific on ARM EHABI architectures. I spent a lot of time to decipher it, and mostly based the implementation on how libgcc / libstdc++ handle this... But it may be different for musl. See There is also an opened issue with unwinding and static binaries on musl/alpine. |
@ysbaddaden Aha! The above error is from static binary (I’m building static crystal binaries to be used for bootstrapping normal builds), so I’ll try dynamic binary. |
You can build glibc static binaries to help bootstrapping. There will be the usual warnings, but meh, the binary will be good enough for bootstrap a native build —this is how I initially added support for alpine x86. |
It seems that even dynamically linked does not work. :( Building crystal with dynamically linked crystal built on armv6 machine:
|
You may look for the If it still fails, you may investigate by cross building each spec and running it one by one on the ARM target —with an automated script— and find what's crashing. Supporting ARM32 isn't an easy feat... |
I wanted to give you access to ARMv7 machine, so you can troubleshoot it, but… it seems that the same binary (built on another ARM machine) does not crash here! 😕 It’s still running, but already passed the time when it repeatedly crashed on the another ARM machine. The machine I use is actually ARMv8, but it is capable running in 32 bit mode. The new one is VM on Scaleway, real ARMv7 machine. |
Okay, I’ve successfully built dynamically linked crystal (3) on musl ARMv7 using crystal (2) compiled on the same machine using crystal (1) cross-compiled from x86_64 musl. I also run specs with the following result:
More details for two randomly selected tests reveals something interesting:
Does these tests pass on glibc armhf? I have an impression that this may not be related to musl bindings at all and it looks like these failing tests and SIGBUS on ARMv8 in 32bit mode may be two different problems. And there’s log for the first failing socket test, it hangs on it:
|
require "./src/compiler/crystal/**"
require "primitives"
include Crystal
code = <<-CODE
lib LibFoo
struct Bar
x : Int32
y : Float32
end
end
bar = LibFoo::Bar.new
bar.y = 2.5_f32
bar.y
CODE
x = Program.new.run(code, debug: Crystal::Debug::None).to_f32
puts x == 2.5
puts x
|
Except for the Target DataLayout, the LLVM IR dump is identical on
Can the program itself print the FP value correctly?
|
lib LibFoo
struct Bar
x : Int32
y : Float32
end
end
bar = LibFoo::Bar.new
bar.y = 2.5_f32
x = bar.y
puts x.to_f32 == 2.5
puts x
puts x / 2
|
@ysbaddaden I’ve prepared you environment on baremetal ARMv7 machine to troubleshoot this issue: |
Thanks! I'll try to have a look over the weekend. I confirm the issue: the LLVMGenericValue doesn't get the value returned by the Crystal module, but from some other place. I had this issue with Crystal expecting the value in a regular CPU registers when a library actually put it in a VFP register. |
How it goes? :) |
Sorry, I didn't have much computer time. I'm not sure I'll have until a while :( |
Is there anything missing for this to be merged? |
I read the thread again, and:
Anyway: those issues aren't related to the |
@jirutka could you rebase the PR? I can check on my side with QEMU if this works then. |
🏓 |
@jirutka might be busy on other topics. |
Can be closed, future work goes to #7859. |
Related to #5467