Skip to content
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

[SR-221] Port Swift to Linux aarch64 (arm64) #42843

gribozavr opened this issue Dec 14, 2015 · 5 comments

[SR-221] Port Swift to Linux aarch64 (arm64) #42843

gribozavr opened this issue Dec 14, 2015 · 5 comments


Copy link

@gribozavr gribozavr commented Dec 14, 2015

Previous ID SR-221
Radar None
Original Reporter @gribozavr
Type New Feature

Attachment: Download

Additional Detail from JIRA
Votes 9
Component/s Compiler
Labels New Feature, Linux, NewPortRequest, aarch64, arm
Assignee None
Priority Medium

md5: d82be33062357aafcd2b8854c9a7d6b9

Issue Description:

Swift builds on Linux aarch64. Here are the results of running the primary testsuite (`ninja check-swift`):

Failing Tests (20):
    Swift :: 1_stdlib/FloatingPointIR.swift
    Swift :: 1_stdlib/Interval.swift
    Swift :: 1_stdlib/Optional.swift
    Swift :: 1_stdlib/Range.swift
    Swift :: 1_stdlib/Reflection.swift
    Swift :: 1_stdlib/VarArgs.swift
    Swift :: Driver/subcommands.swift
    Swift :: IRGen/autorelease.sil
    Swift :: IRGen/c_layout.sil
    Swift :: IRGen/objc_simd.sil
    Swift :: Interpreter/archetype_casts.swift
    Swift :: Interpreter/generic_class.swift
    Swift :: Interpreter/generic_struct.swift
    Swift :: Interpreter/protocol_extensions.swift
    Swift :: Interpreter/protocol_lookup.swift
    Swift :: Interpreter/slices.swift
    Swift :: Parse/BOM.swift
    Swift :: Prototypes/CollectionsMoveIndices.swift
    Swift :: Prototypes/FloatingPoint.swift
    Swift :: Prototypes/TextFormatting.swift

(full logs attached)

One of the issues is that existentials of types defined in the standard library don't work: the value witness table pointer in the struct type metadata is null.

Here's a minimal reproducer:

$ cat crash.swift
protocol P {
  func setValue()

extension Bool : P {
  func setValue() {}

func zzz() {
  var someP: P = true



Program received signal SIGSEGV, Segmentation fault.
0x0000000000400be8 in _TF5crash3zzzFT_T_ ()
(gdb) disas
Dump of assembler code for function _TF5crash3zzzFT_T_:
   0x0000000000400b9c <+0>: stp x29, x30, [sp,#-16]!
   0x0000000000400ba0 <+4>: mov x29, sp
   0x0000000000400ba4 <+8>: sub sp, sp, #&#8203;0x80
   0x0000000000400ba8 <+12>:    add x0, sp, #&#8203;0x30
   0x0000000000400bac <+16>:    sub x1, x29, #&#8203;0x28
   0x0000000000400bb0 <+20>:    orr w8, wzr, #&#8203;0x1
   0x0000000000400bb4 <+24>:    adrp    x9, 0x411000
   0x0000000000400bb8 <+28>:    add x9, x9, #&#8203;0x30
   0x0000000000400bbc <+32>:    adrp    x10, 0x411000
   0x0000000000400bc0 <+36>:    ldr x10, [x10,#736]
   0x0000000000400bc4 <+40>:    stur    x10, [x29,#-16]
   0x0000000000400bc8 <+44>:    stur    x9, [x29,#-8]
   0x0000000000400bcc <+48>:    and w8, w8, #&#8203;0x1
   0x0000000000400bd0 <+52>:    sturb   w8, [x29,#-40]
   0x0000000000400bd4 <+56>:    ldur    x9, [x29,#-16]
   0x0000000000400bd8 <+60>:    str x9, [sp,#72]
   0x0000000000400bdc <+64>:    ldur    x10, [x29,#-8]
   0x0000000000400be0 <+68>:    str x10, [sp,#80] // load the metadata pointer
   0x0000000000400be4 <+72>:    ldur    x10, [x9,#-8] // load the value witness table pointer 
=> 0x0000000000400be8 <+76>:    ldr x10, [x10,#8] // dereference it, but x10 is null
   0x0000000000400bec <+80>:    mov x2, x9
   0x0000000000400bf0 <+84>:    blr x10

What is strange though is that somehow the resulting binary tries to define metadata symbol, but in BSS (?!)

$ nm crash | grep _TMSb
0000000000411338 B _TMSb

The definition does not exist in the IR.

The symbol looks fine in the library though:

$ nm ./build/Ninja-ReleaseAssert/swift-linux-aarch64/lib/swift/linux/ | grep _TMSb
00000000003db4f8 D _TMSb

I suspect a bug in binutils.

$ ld --version
GNU ld (GNU Binutils for Debian)
Copy link

@hpux735 hpux735 commented Mar 17, 2016

This is still broken in binutils 2.26, and broken in gold.

Copy link

@swift-ci swift-ci commented Jun 28, 2017

Comment by Adam Duracz (JIRA)

Any news on this? I see some traces of support and, with a patched binutils, building 3.1.1 succeeds, but there are still failed tests.

Copy link

@swift-ci swift-ci commented Jul 12, 2017

Comment by Adam Duracz (JIRA)

Let me elaborate. I am working in a DARPA-funded project that is developing a system that depends on having Swift running on an aarch64-based hardware platform running 64-bit Ubuntu Linux 16.04. So far, after patching binutils on the system, we have been able to successfully build Swift, but see 40+ failing test cases (see swift-3.0.2-test.log) when running the Swift test suite. Our system relies on Swift Package Manager, so Swift 3.x is a requirement. Do you know of any way of getting this running on the target platform? We are currently trying to compile a 32-bit version, after seeing signs of success of doing so on a 64-bit RPi platform. Also, if you are aware of the state/perspective of adding support for this at Apple, that would be very helpful.

After a suggestion from @hpux735 that several of the failures seem related to reflection, we are planning to start looking at the 1_stdlib/Mirror.swift failure first.

Copy link

@swift-ci swift-ci commented Jun 27, 2018

Comment by Ed Vielmetti (JIRA)

There is a CI project going to build Swift on arm64, through the Works on Arm project.

WorksOnArm/equinix-metal-arm64-cluster#62 is the open issue, and currently we're blocked on SR-2239 `CVaListPointer` does not gets converted to `va_list` on `aarch64`

Copy link

@hpux735 hpux735 commented Oct 9, 2018

Please see Kaiede's Trello board for this work

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

3 participants