Swift 6.0.1 for Gentoo on GURU

Community Showcase
,
8

Okay, I've confirmed that this appears to be a difference between building Swift 6.0.1 using Swift 5.10.1 or 6.0.1 itself. With the same exact settings, in the same exact environment, building Swift 6 using 5.10 leads to a broken repl and lldb, whereas building with Swift 6 leads to working tools. :thinking:

It's not yet clear why this would be the case, but I don't believe this to be intentional; based on discussion from RFC: Requiring Swift to build the Swift toolchain, I would expect it to be possible to bootstrap a Swift 6 setup from Swift 5.10 directly, without needing a multi-stage compilation process (e.g., build an initial Swift 6 compiler using Swift 5.10, then use that compiler to rebuild another Swift 6 compiler).

I'll see what I can figure out from here.

(This means that at the moment, the first time you install Swift 6 and bootstrap using Swift 5.10.1, you'll end up with a broken repl; upon the first update to Swift 6, you'll build using Swift 6, and it'll work again.)

By the way, the failure mode appears to be that whatever you attempt to run in the repl causes a StructInst to fail validation as a ForwardingInstruction:

$ ./swift repl
Welcome to Swift version 6.0.1-dev (LLVM 43d73cb0cc589f7, Swift 15672c560c7fd09).
Type :help for assistance.
  1> "Hello"
Optimizer/Verifier.swift:22: Fatal error: instruction <StructInst>   %14 = struct $Int32 (%13 : $Builtin.Int32)      // user: %15
should conform to ForwardingInstruction

This is interesting, because extension StructInst : ForwardingInstruction { conformance is declared in ForwardingInstruction.swift. :thinking:

Edit:

In both the success case and the failure case, I see hits for symbols containing ForwardingInstruction in the following files:

$ find . -mindepth 1 -type f -executable -exec sh -c 'if nm "{}" 2>/dev/null | grep -q ForwardingInstruction &>/dev/null; then echo "{}"; fi' ';'
./usr/bin/swift-frontend
./usr/bin/lldb-server
./usr/lib/swift/host/lib_InternalSwiftScan.so
./usr/lib/libsourcekitdInProc.so
./usr/lib/liblldb.so.17.0.0

All of these files have almost the same symbols (at different offsets, of course), and all have the StructInst conformance to ForwardingInstruction:

0000000006828a10 t $s3SIL10StructInstCAA21ForwardingInstructionA2aDP17preservesIdentitySbvgTW
0000000006828a40 t $s3SIL10StructInstCAA21ForwardingInstructionA2aDP21canForwardOwnedValuesSbvgTW
0000000006828a00 t $s3SIL10StructInstCAA21ForwardingInstructionA2aDP22singleForwardedOperandAA0H0VSgvgTW
0000000006828a20 t $s3SIL10StructInstCAA21ForwardingInstructionA2aDP23preservesRepresentationSbvgTW
0000000006828a30 t $s3SIL10StructInstCAA21ForwardingInstructionA2aDP26canForwardGuaranteedValuesSbvgTW
00000000078ddcc0 d $s3SIL10StructInstCAA21ForwardingInstructionAAMc
0000000006bf72c8 d $s3SIL10StructInstCAA21ForwardingInstructionAAWP

The only outlier is lldb-server from the successful build, which lacks almost all of these symbols — but replacing it with the lldb-server binary from the failure case doesn't appear to make a difference.

My next guess, then, is that it's not that the conformance is missing, but that something about the runtime is failing to pick it up.

Edit 2: Okay, I've bisected the failing lib down to liblldb.so.17.0.0: running the successful Gentoo build with the failing build's liblldb.so.17.0.0 reproduces the failure; no other library change does.

Now I need to see if I can figure out what's changed between these versions.

1 Like