21

@Finagolfin I have finished all the setup for the server and we should be ready to go.
Just posted details about the project here - Swift Arm Community CI Server

I have setup a project for Swift on Armv7 and it is ready for PR's and patch testing.

1 Like
22

Thanks for setting that up and letting us know. I'll take a look at the current stdlib build failure and I've let others know who use Swift on 32-bit ARM, so hopefully we can get that working well.

I haven't run into this issue with my Android armv7 builds, maybe because I cross-compile the toolchain from linux x86_64 while you are natively compiling it on armv7.

23

Since this was thread was originally about targeting 32-bit systems, and it’s now about hosting the toolchain on 32-bit systems, I think we should probably start a new thread over in Compiler Development. I could move all the recent posts over if people are okay with that.

3 Likes
24

I agree, I think too much importance is being put into hosting the Swift compiler on 32 bit platforms (like Armv7) instead of having distributable builds for the runtime and cross compiling. I have projects to build Swift 5.6.1 and its runtimes libraries for Debian 11 and Buildroot. Currently working on Yocto as well. I've been testing and maintaining this port since last year, staring with only Buildroot.

1 Like
25

I don't want to say that hosting on 32-bit systems is unimportant, just that hosting and targeting are pretty different projects with different needs, and this thread was originally focused on just one of them.

1 Like
26

I think it's great to have that, but realistically it should be a higher priority to get Swift supported on as many platforms as possible targeting cross compilation first. I think it's counterproductive to focus first on hosting the compiler because it will be a lot of work, and once all that is merged is done, you still need to patch the runtime to get a usable product. It would be extremely beneficial for the adoption of Swift to verify 32 bit support is solid (ideally Armv7 since that is a huge commercial and hobby platform) before each release with a platform champion as is the case with Windows currently. The company where I work at relies on Swift for Linux Armv7 for multiple IoT products and it's pretty much broken every release in one way or another and we are always catching up. Another benefit to focusing on the runtime is that we can use existing x86 infrastructure for cross compilation and try to get that officially supported, compared to compiler ports like Linux Armv7 and PPC 64 that have been pretty much abandoned and need to be compiled and testing on dedicated hardware.

27

I've started another thread specifically for Swift on Linux Armv7

28

fwiw, x-compile tooling was a major topic in the first embedded systems call two weeks ago. I mentioned the great work you and @futurejones do :)

1 Like
29

it should be a higher priority to get Swift supported on as many platforms as possible targeting cross compilation first.

Agreed, cross-compilation is easier.

I think it's counterproductive to focus first on hosting the compiler because it will be a lot of work

Not really, the Swift compiler is mostly written in C++, so if you're happy with C++ compilation for your platform, building the compiler should just work. Of course, building the compiler generally for 32-bit platforms has regressed a couple times, so issues do come up with C++ too, but I currently distribute a working Swift 5.6.1 toolchain that runs natively on Android armv7 devices, AFAIK the only up-to-date 32-bit Swift toolchain.

The current issue with linux armv7 is actually building the Swift stdlib with the native bootstrap compiler causing a compiler crash, not any C++ errors when building the Swift compiler itself.

It would be extremely beneficial for the adoption of Swift to verify 32 bit support is solid (ideally Armv7 since that is a huge commercial and hobby platform) before each release with a platform champion as is the case with Windows currently. The company where I work at relies on Swift for Linux Armv7 for multiple IoT products

You may be the ideal champion then. :wink:

While everyone agrees that porting the Swift runtime should come before porting the compiler, @oof actually started this thread asking about the latter and it is more general and a superset of just getting the runtime working. For example, once you have the Swift compiler and other testing tools working natively, you can run the entire compiler validation suite, including the 1k executable tests, and really exercise platform support.

I just ran the compiler validation suite for the first time on the 32-bit Android armv7 compiler (not including the tests that require tools like swift-ide-test) on my Android AArch64 phone, and found less than 200 tests with different results when running the Android Aarch64 compiler similarly, out of around 13k tests in the suite. That is not easy to do when just cross-compiling the runtime, though the Android armv7 CI does run around 12k of those tests on linux x86_64, ie excluding the 1k tests that require running a cross-compiled executable natively.

5 Likes
30

Now that embedded Swift is being worked on, is there any interest from the community in setting up an official 32-bit CI, maybe linux-armv7 or linux-riscv32, something to at least keep all the tests working for 32-bit? I suggested to @kubamracek that we could set one up in one of the official linux AArch64 CI images, since most linux distros also support running 32-bit code, as I noted earlier in this thread.

I help maintain the only public 32-bit Swift CI that I know of, the Android armv7 community CI, which cross-compiles the compiler validation suite from linux x86_64 to Android armv7 but doesn't run the thousand or so executable tests. If we set up the 32-bit runtime in a linux AArch64 CI image, we can run all those tests too (doesn't make sense to simply expand Android armv7 instead because that is a dying platform, with the latest Snapdragon 8 Gen 3 dropping AArch32 support altogether).

I can kick this off by contributing a Dockerfile and CI config to do this, if given the go-ahead to do so on the official CI, but I'm really not looking for another CI platform to maintain myself after that. I'd be happy to be part of a team maintaining such a 32-bit CI though, as @futurejones tried to set up before, so if you would contribute to such a team too, here's your chance to let us know.

3 Likes
31

IIRC the Windows CI is capable of compiling a x86 SDK, and that works well. I think it’s just not collected as an artifact…?

1 Like
32

You are correct! We actually do include it in 5.10 and newer, but we do not have a snapshot for that yet. However, I think that the latest installer for main should have it included.

The problem with the x86 SDK is that there is a problem with SIL representation of calling convention that results in them being dropped and thus you cannot always call into the system APIs, but otherwise it should be usable.

33

32-bit ARMv7 support on Linux would be welcome here. Last time I looked the current tool chain only worked on 64-bit?

34

I think I distribute the only remaining up-to-date 32-bit Swift toolchain, which you can run in the Termux app on an old Android armv7 device. However, I have not tested it in more than a year, so unsure how well it works anymore.

In any case, considering how underpowered most 32-bit devices are compared to most 64-bit devices these days, we only need to focus on cross-compiling the 32-bit Swift stdlib and keeping the compiler validation suite up to date on some CI.

So far, I'm the only person who's volunteered to partially maintain such a 32-bit CI, in addition to setting it up myself, so if nobody else does, it's not going to happen.

1 Like
35

At least for Windows, I do not expect to ship a 32-bit toolchain. The address space limitations make it too difficult to work in that environment as most environments have shifted to 64-bits. I think that for development it makes sense to expect a 64-bit host. However, you can build a 32-bit application with the 64-bit toolchain and distribute the application to run on a 32-bit system. The distinction here being the runtime versus the toolchain tools.

36

Can macOS host be used to build and debug Swift apps on Windows / Linux targets?

37

It should be possible to do Linux targets if you build the SDK for the distribution.

For Windows, it is possible to debug remotely. For building applications, there is ambiguity about the acquisition of the Windows system headers and libraries which are part of the Windows SDK and Visual Studio packages.

38

Yes, but there are subtle issues with the closed Xcode toolchain, so you are better off using the OSS toolchain from Homebrew.

Or you could download the linux toolchain onto macOS and use the prebuilt Swift resource directory for linux from there.

39

@orobio and I have been in talks with the Swift core team regarding just this. 32-bit builds are certainly possible to create, as evidenced by the various community ports (buildSwiftOnArm, swift-armv7, and more), but in the end it's just a bunch of forks rather than putting that effort back into the swift runtime and CI.

So, we'd like to work with community members and the Swift team to start setting up an official armv7 CI (ideally targeting Debian to start) so we can start supporting armv7/armhf officially with each release.

Would anyone be interested in contributing to that effort? Neither @orobio nor I have much experience in what goes into actually building Swift for armv7, which is why we need some help in that area.

7 Likes
40

Sounds good. My understanding is that someone proposes a swift-docker image and if approved for the official CI, that will be added: you can see a list of currently officially supported platforms for the main Swift branch here. Perhaps @mishal_shah can fill us in on any other requirements.

Once it is up and running, it's mostly a bunch of 32-bit gardening. For example, this Swift IRGen test just broke on the Android armv7 community CI:

Exit Code: 1

Command Output (stderr):
--
/home/ubuntu/jenkins/workspace/oss-swift-RA-linux-ubuntu-16.04-android/buildbot_linux/swift-linux-x86_64/test-android-armv7/IRGen/Output/static-vtable-stubs.swift.tmp/B.swift:33:11: error: CHECK: expected string not found in input
// CHECK: declare swiftcc { ptr, ptr } @"$s1M1CC1i33_807E3D81CC6CDD898084F3279464DDF9LLSDySOypGvM"(ptr noalias dereferenceable(32), ptr swiftself) #0
          ^
<stdin>:113:104: note: scanning from here
declare swiftcc void @"$s1M1CC1i33_807E3D81CC6CDD898084F3279464DDF9LLSDySOypGvs"(ptr, ptr swiftself) #0
                                                                                                       ^
<stdin>:115:1: note: possible intended match here
declare swiftcc { ptr, ptr } @"$s1M1CC1i33_807E3D81CC6CDD898084F3279464DDF9LLSDySOypGvM"(ptr noalias dereferenceable(16), ptr swiftself) #0
^

The issue appears to be the dereferenceable(16) on armv7, so the test will need to be amended to accept both, ie something like dereferenceable({{32|16}}) should fix it on armv7.

@kubamracek, would you or some of the other devs working on embedded Swift be able to collaborate with the community to get an official 32-bit armv7 CI started and keep it maintained?

2 Likes