Swift 4.1 on ARMv7

Development Compiler
,
1

Hi everyone.
Over in the Swift on ARM/Linux camp, we’ve been stuck on Swift 3.1.1 for quite some time. This is primarily due to two reasons:

  1. Lack of resources: we’re all volunteers, and are running out of free time to keep up with the rapid pace of development in the compiler.
  2. Regressions due to rapid pace of development: Unlike supported platforms, ARM/Linux does not have any visibility in the CI infrastructure. Many otherwise innocent changes to the compiler and its associated components may cause regressions on ARM/Linux that go unnoticed for months. This make is very difficult for us to identify changes that cause problem.

I realize that there’s nothing to be done for #1 (unless Apple hires an engineer or two to work on ARM/Linux ), and that there may be some answer to #2 at some point in the future.

For the purposes of this thread, I want to call attention to the following issue to get us started in getting Swift 4.1 ready for use.

Swift 4.1 SwiftPM – There is an assertion that appears to be thrown from from glibc in swift-build-stage1 The assertion is here, specifically: malloc.c source code [glibc/malloc/malloc.c] - Codebrowser
It should be said that, aside from that the the REPL, it appears that the 4.1 compiler seems basically functional.

Currently failing Swift 4.1 tests:
 ********************
 Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
 Testing Time: 2259.75s
 ********************
 Failing Tests (8):
     Swift(linux-armv7) :: IRGen/c_layout.sil
     Swift(linux-armv7) :: stdlib/Runtime.swift.gyb
     Swift(linux-armv7) :: SILOptimizer/redundant_load_elim.sil
     Swift(linux-armv7) :: ClangImporter/clang_builtins.swift
     Swift(linux-armv7) :: Runtime/backtrace.swift
     Swift(linux-armv7) :: Misc/expression_too_complex.swift
     Swift(linux-armv7) :: Runtime/weak-reference-racetests.swift
     Swift(linux-armv7) :: IRGen/condfail.sil
   Expected Passes    : 2989
   Expected Failures  : 78
   Unsupported Tests  : 1047
   Unexpected Failures: 8

I also want to point out that I have access to cloud-based ARMv7 systems that may be used by anyone seriously interested in helping development.

14 Likes
2

There is one more known bug that appears on some systems and kernel configurations. The built llvm issues an invalid instruction vmov.i32. I can identify the exact .td that first causes this issue.

-- Build files have been written to: /root/buildSwiftOnARM/build/buildbot_linux/llvm
+ popd
~/buildSwiftOnARM
symlinking the system headers (/usr/include/c++) into the local clang build director
+ ln -s -f /usr/include/c++ /root/buildSwiftOnARM/build/buildbot_linux/llvm-linux-ar
+ /usr/bin/cmake --build /root/buildSwiftOnARM/build/buildbot_linux/llvm-linux-armv7
[148/2256] Building Attributes.inc...
FAILED: cd /root/buildSwiftOnARM/build/buildbot_linux/llvm-linux-armv7/include/llvm/
Illegal instruction

This appears related to a regression introduced in LLVM-3.8 that failed to correctly detect whether the processor supported NEON instructions, and would default to using them all the time. Related bug report

1 Like
3

Uranimo created a tracking dashboard for ARM bugs: Issues · apple/swift · GitHub

Thanks!!

4

I cannot provide any input to the major issue, but I cannot wait until I can grab my dusty raspberry pi 3 and start coding on it in Swift 4.1. :man_technologist:

7 Likes
5

Hi, thanks for all your great work on Swift-Arm. Can you give me some more info on the cloud-based ARM7 system. Is this a better option to building on a Raspberry Pi 3?

6

I had hoped so, but there's a bug in the Debian-packaged LLVM wherein it always produces NEON instructions, regardless of whether the underlying CPU supports it. So, when the Swift build scripts begin using its own compilers and tools they get illegal instructions, and crash.

I haven't had time to compile replacements for LLVM and Clang that don't have this yet, so you'er better off with a Raspberry Pi.

7

Ok, thanks.

8

As far as the NEON issue goes, you could try adding -Xcc -mattr=-neon (for Swift) or -mattr=-neon (for Clang) and see if that makes the problem go away.

9

Thanks Jordan! I'll try that. I'm guessing I can add that to the build-script-impl arguments, or would I have to hack the scripts to add it?

10

I'm not sure there's an obvious place to pass it, but if you were hacking things build-script-impl has a COMMON_C_FLAGS variable that you can add this too, just to try.

11
12

I wonder if the community based CI for ARMv7 does cover linux support for devices like the 32Bit Raspberry Pi? (I'm not experienced with hardware architectures that much so I cannot really tell the difference.)

13

It will in the sense that the Raspberry Pi is a simple Armv7l. There are many devices that are similar. The tricky thing about the Raspberry Pi is that the libraries aren't standard relative to other distributions (if using Raspian). The way the Swift compiler is built, it matters the exact library version, and install location.

What this means is that whether the build succeeds is almost certainly going to be representative for the Raspberry Pi, but the binary won't be directly usable.

1 Like
14

Now with GitHub - apple/swift-community-hosted-continuous-integration: Swift Community-Hosted Continuous Integration adding Raspian will suffice for supporting most Rasberry Pi usage?

15

Yes, that's correct.

16

Sorry to hijack the thread a little, but while we are on the topic of Swift for ARM, I would like to play with my Raspberry Pi over the weekend and make something with Swift.

The last time I was using Swift on the Pi was a great experience but it was still Swift 3 (mid-2017). Could somebody with more knowledge point me to some precompiles binaries to run Swift 4.1 on the Pi? Or if that is unavailable, could somebody point me to some new articles or other resources on how can I build Swift 4.1 and use it on Raspberry?

17

Yes, we have binaries for 4.1, and we're starting to seriously work on merging changes back into GitHub - apple/swift: The Swift Programming Language. The best place to connect with this development work is the SwftArm slack channel

1 Like
18

Do those binaries include the Swift PM yet?

If so, is there a trick to building them - I used uraimo's current buildSwiftOnARM but the swiftpm bootstrap fails:

swift-build-stage1: malloc.c:2406: sysmalloc: Assertion
  `(old_top == initial_top (av) && old_size == 0)
   || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top)
   && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
19

The only problem I’ve had with building on the raspberry pi is that it tends to run out of memory, and eventually stops due to requesting a larger page than what the raspbian kernel supports by default. I suppose the easiest method might be to compile this on qemu. I’m not sure if there’s a better way.

20

can't you cross-compile for ARM?