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

[gribozavr]

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
  someP.setValue()
}

zzz()

gdb:

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/libswiftCore.so | grep _TMSb
00000000003db4f8 D _TMSb

I suspect a bug in binutils.

$ ld --version
GNU ld (GNU Binutils for Debian) 2.25.90.20151209

[hpux735]

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

[swift-ci]

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.

[swift-ci]

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.

[swift-ci]

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 https://bugs.swift.org/browse/SR-2239 `CVaListPointer` does not gets converted to `va_list` on `aarch64`

[hpux735]

Please see Kaiede's Trello board for this work https://trello.com/b/G6lK1Enh/swift-master-on-arm-i686-linux