Open swift-ci opened 6 years ago
cc @milseman
So tracing through the logic, this is a little weird. asowani (JIRA User) can you post the git hash where you have the stack trace from? Can you verify what is in /root/latest/swift-source/swift/stdlib/public/core/Builtin.swift, line 466? If you can't finish a full Debug build, can you try with `build-script -r`, which will keep some debug info around and assertions too?
If the same as master at https://github.com/apple/swift/blob/master/stdlib/public/core/Builtin.swift#L466, then it seems like it's seeing a tagged bit pattern. This may be an issue on platforms where our runtime doesn't have support for tagged patterns in bridge objects, which we're leveraging to represent String literals and small strings. CC @jckarter and @gparker42.
That seems likely. We only specifically use tagged patterns on platforms we've opted into them, like x86_64 and arm64, and the default target info without any customization would not assume anything about the address space and not use high tag bits at all. Maybe we just need to add or customize a SwiftTargetInfo
for ppc64le in IRGen.
We'd like to use the same pattern for all 64-bit ABIs. Should we just change the value of SWIFT_ABI_DEFAULT_OBJC_RESERVED_BITS_MASK based on 64-bit or something like that? What do you think is cleanest?
Making it consistent would be cleanest for sure, but I don't know what the constraints if any on PPC64 platforms in the wild are. We have some guarantees that Apple ARM64 and x86_64 platforms won't use more than the low 56 bits of address space for user mode, but I don't know whether ppc platforms make any similar promises.
asowani (JIRA User), do you know what ppc64le's guarantees concerning user mode address spaces are?
Comment by Atul Sowani (JIRA)
I re-built swift using "-r" option.When the build crashed, I ran it through gdb which yielded following:
warning: Could not find DWO CU /root/latest/swift-source/buildbot_incremental/swift-linux-powerpc64le/module-cache/6HHA0BVHXTL9/SwiftShims-1IPGKDU80LD57.pcm(0x8748742808ee24fd) referenced by CU at offset 0x2e5388 [in module /root/latest/swift-source/buildbot_incremental/swift-linux-powerpc64le/lib/swift/linux/libswiftCore.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0xea888 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0xee6ff [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0xf01af [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0xf1007 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0xfbe3b [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x120198 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/SwiftGlibc-18508AN2IPOUC.pcm(0xf4a5f30bbc7a2f09) referenced by CU at offset 0x1201c2 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x167b45 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x17d4e4 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x18763a [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x194217 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x1d24b5 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x206c31 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/SwiftShims-1IPGKDU80LD57.pcm(0x99f198308ae37944) referenced by CU at offset 0x20bcc2 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/buildbot_incremental/swift-linux-powerpc64le/module-cache/3JLXVOYZ8I8ZK/SwiftShims-1IPGKDU80LD57.pcm(0x34e1e7c6995cb4b9) referenced by CU at offset 0x2471 [in module /root/latest/swift-source/buildbot_incremental/swift-linux-powerpc64le/lib/swift/linux/libswiftGlibc.so]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
Fatal error: file /root/latest/swift-source/swift/stdlib/public/core/Builtin.swift, line 466
Current stack trace:
0 libswiftCore.so 0x00003fffb7e000f0 _swift_stdlibreportFatalErrorInFile + 276
1 libswiftCore.so 0x00003fffb7d40e88 \<unavailable> + 5967496
2 libswiftCore.so 0x00003fffb7d408fc \<unavailable> + 5966076
3 libswiftCore.so 0x00003fffb7944688 \<unavailable> + 1787528
4 libswiftCore.so 0x00003fffb7d40c18 \<unavailable> + 5966872
5 libswiftCore.so 0x00003fffb7d40854 \<unavailable> + 5965908
6 libswiftCore.so 0x00003fffb7944688 \<unavailable> + 1787528
7 libswiftCore.so 0x00003fffb7c84554 \<unavailable> + 5195092
8 libswiftCore.so 0x00003fffb7c843b4 \<unavailable> + 5194676
9 libswiftCore.so 0x00003fffb7944688 \<unavailable> + 1787528
10 libswiftCore.so 0x00003fffb7943c40 fatalErrorMessage(:_:file:line:flags🙂 + 212
11 libswiftCore.so 0x00003fffb7c32830 \<unavailable> + 4859952
12 libswiftCore.so 0x00003fffb7c4aa20 \<unavailable> + 4958752
13 libswiftCore.so 0x00003fffb7be4b58 \<unavailable> + 4541272
14 libswiftCore.so 0x00003fffb7db2a4c \<unavailable> + 6433356
15 libstdc++.so.6 0x00003fffb66c2f00 \_once_proxy + 52
16 libpthread.so.0 0x00003fffb69422f4 \<unavailable> + 74484
17 libswiftCore.so 0x00003fffb7db2950 swiftonce + 120
18 libswiftCore.so 0x00003fffb7be4c30 static CommandLine.arguments.getter + 52
19 swift-build-stage1 0x000000002004d0d0 \<unavailable> + 315600
20 libc.so.6 0x00003fffb631309c \<unavailable> + 143516
21 libc.so.6 0x00003fffb63131e0 \_libc_start_main + 184
Comment by Atul Sowani (JIRA)
@milseman I am using master branch for build. /root/latest/swift-source/swift/stdlib/public/core/Builtin.swift:466 is the first _sanityCheck statement in the following code snippet:
@inline(__always)
@inlinable
public func _bridgeObject(fromTagged x: UInt) -> Builtin.BridgeObject {
_sanityCheck(x & _objCTaggedPointerBits != 0)
let object: Builtin.BridgeObject = Builtin.valueToBridgeObject❌
_sanityCheck(_isTaggedObject(object))
return object
}
Comment by Atul Sowani (JIRA)
@jckarter @milseman - I am checking for user mode address space guarantees on ppc64le.
Comment by Atul Sowani (JIRA)
BTW, would it help if I setup a CI for Swift on ppc64le?
I think that would be immensely helpful. I don't know if there's currently a policy for new CI platforms. CC @tkremenek and najacque (JIRA User).
Comment by Nicole Jacque (JIRA)
asowani (JIRA User) yes please! I will send you an email to discuss.
Comment by Atul Sowani (JIRA)
@jckarter @milseman What I learned from Power Linux kernel developers is that Power supports 4PB of user address space which is equivalent to 52 bits. If you need any specific information, please let me know.
Since I am not an expert in kernel, is it possible for you/Swift community to interact with Power Linux kernel experts on a public forum? If yes, I can initiate the dialog there and provide details to both communities.
Thanks!
Are they able to comment on a thread at forums.swift.org?
For the address space, I think we should do something like the following:
diff --git a/stdlib/public/SwiftShims/System.h b/stdlib/public/SwiftShims/System.h
index abe42c119d2..6cce9985d48 100644
--- a/stdlib/public/SwiftShims/System.h
+++ b/stdlib/public/SwiftShims/System.h
@@ -62,6 +62,8 @@
#define SWIFT_ABI_DEFAULT_OBJC_WEAK_REFERENCE_MARKER_MASK 0
#define SWIFT_ABI_DEFAULT_OBJC_WEAK_REFERENCE_MARKER_VALUE 0
+#define SWIFT_ABI_DEFAULT_64BIT_SPARE_BITS_MASK 0xFF00000000000007ULL
+
/*********************************** i386 *************************************/
// Heap objects are pointer-aligned, so the low two bits are unused.
@@ -100,7 +102,8 @@
#define SWIFT_ABI_DARWIN_X86_64_LEAST_VALID_POINTER 0x100000000ULL
// Only the bottom 56 bits are used, and heap objects are eight-byte-aligned.
-#define SWIFT_ABI_X86_64_SWIFT_SPARE_BITS_MASK 0xFF00000000000007ULL
+#define SWIFT_ABI_X86_64_SWIFT_SPARE_BITS_MASK \
+ SWIFT_ABI_DEFAULT_64BIT_SPARE_BITS_MASK
// Objective-C reserves the high and low bits for tagged pointers.
// Systems exist which use either bit.
@@ -126,7 +129,8 @@
// TBI guarantees the top byte of pointers is unused.
// Heap objects are eight-byte aligned.
-#define SWIFT_ABI_ARM64_SWIFT_SPARE_BITS_MASK 0xFF00000000000007ULL
+#define SWIFT_ABI_ARM64_SWIFT_SPARE_BITS_MASK \
+ SWIFT_ABI_DEFAULT_64BIT_SPARE_BITS_MASK
// Objective-C reserves just the high bit for tagged pointers.
#define SWIFT_ABI_ARM64_OBJC_RESERVED_BITS_MASK 0x8000000000000000ULL
@@ -147,11 +151,13 @@
/*********************************** powerpc64 ********************************/
// Heap objects are pointer-aligned, so the low three bits are unused.
-#define SWIFT_ABI_POWERPC64_SWIFT_SPARE_BITS_MASK 0x0000000000000007ULL
+#define SWIFT_ABI_POWERPC64_SWIFT_SPARE_BITS_MASK \
+ SWIFT_ABI_DEFAULT_64BIT_SPARE_BITS_MASK
/*********************************** s390x ************************************/
// Top byte of pointers is unused, and heap objects are eight-byte aligned.
-#define SWIFT_ABI_S390X_SWIFT_SPARE_BITS_MASK 0x0000000000000007ULL
+#define SWIFT_ABI_S390X_SWIFT_SPARE_BITS_MASK \
+ SWIFT_ABI_DEFAULT_64BIT_SPARE_BITS_MASK
#endif /* SWIFT_ABI_SYSTEM_H */
This puts Swift's generic 64-bit ABI at up to 56 bits of address space (needed for String to have same representation across these platforms). Swift's generic ABI also assumes that the first 4kb of addresses are outside of user-space address space (which is unchanged). Just to double check, is this ok for PPC64?
We should also check with the s390x people. Anyone know who to contact for that?
Comment by Sarvesh Tamba (JIRA)
Hi,
We are trying to build Apple Swift on ppc64le Ubuntu16.04. We built it on ppc64le using a build script at the following link:-
With this we were able to run the 'swiftc' and REPL environment for some basic "Hello World" type of code. However for complex codes, like import Foundation, it fails(probably due to Package manager issues). When we use "import Foundation" with swift, compile error occurs as below is seen:
(swift) import Foundation \<REPL Input>:1:8: error: no such module 'Foundation' import Foundation ^
We are trying to build Swift 4.2(since Swift v4.1 has been released now and no further development is happening on this branch.) on Power8/LE (ppc64le) using the build-toolchain, in order to build the Swift package manager and other tools.
We are seeing a crash which is traceable till following function in HeapObject.cpp file:
static HeapObject *swift_retain(HeapObject *object) { SWIFT_RT_TRACK_INVOCATION(object, swift_retain); if (isValidPointerForNativeRetain(object)) object->refCounts.increment(1); return object; }
Beyond this debugging using simple print statements is tricky and the code flow is unclear. Breakpoints cannot be set since building code in debug mode is not possible as it runs out of resources and hangs.
Any help here would be greatly appreciated. Any more outputs, errors can be shared.
Looking forward to port Apple Swift on Ubuntu16.04.
Regards,
Sarvesh Tamba
Comment by Sarvesh Tamba (JIRA)
I tried to build Swift 4.2 in debug mode. I applied the patch mentioned in "https://github.com/apple/swift/pull/16425" for "stdlib/public/SwiftShims/System.h" as well. However, I am facing similar issues as reported above in "https://bugs.swift.org/browse/SR-7441" :-
— bootstrap: note: building runtime v4 target: PackageDescription4:
Compile Swift Module 'PackageDescription' (9 sources)
Link PackageDescription
— bootstrap: note: building self-hosted 'swift-build': env SWIFT_EXEC=/root/swift-source/Ninja-DebugAssert/swiftpm-linux-powerpc64le/powerpc64le-unknown-linux/debug/swiftc SWIFTPM_BUILD_DIR=/root/swift-source/Ninja-DebugAssert/swiftpm-linux-powerpc64le /root/swift-source/Ninja-DebugAssert/swiftpm-linux-powerpc64le/powerpc64le-unknown-linux/debug/swift-build-stage1 --disable-sandbox -Xlinker -rpath -Xlinker $ORIGIN/../lib/swift/linux -Xlinker -L -Xlinker /root/swift-source/Ninja-DebugAssert/foundation-linux-powerpc64le/Foundation -Xlinker -rpath -Xlinker /root/swift-source/Ninja-DebugAssert/foundation-linux-powerpc64le/Foundation -Xswiftc -I/root/swift-source/Ninja-DebugAssert/foundation-linux-powerpc64le/Foundation -Xswiftc -I/root/swift-source/Ninja-DebugAssert/foundation-linux-powerpc64le/Foundation/usr/lib/swift -Xlinker -L -Xlinker /root/swift-source/Ninja-DebugAssert/xctest-linux-powerpc64le -Xlinker -rpath -Xlinker /root/swift-source/Ninja-DebugAssert/xctest-linux-powerpc64le -Xswiftc -I/root/swift-source/Ninja-DebugAssert/xctest-linux-powerpc64le -Xlinker -L/root/swift-source/Ninja-DebugAssert/libdispatch-linux-powerpc64le/src/.libs -Xswiftc -I/root/swift-source/Ninja-DebugAssert/libdispatch-linux-powerpc64le/src -Xswiftc -I/root/swift-source/Ninja-DebugAssert/libdispatch-linux-powerpc64le/src/swift -Xswiftc -I/root/swift-source/swift-corelibs-libdispatch -Xcc -fblocks --build-tests
Fatal error: file /root/swift-source/swift/stdlib/public/core/Builtin.swift, line 466
Current stack trace:
0 libswiftCore.so 0x00003fffaaf67150
Comment by Sarvesh Tamba (JIRA)
Hi Team, any insights on the above errors?
Comment by Sarvesh Tamba (JIRA)
On closer investigation, realised that the string implemetation has changed in Swift 4.2 from that in Swift 4.1 to a large extent.
The crash involves changes in String.swift besides the newly introduced StringGuts.swift and StringObject.swift files.
In the StringGuts.swift file there are comments such as "// FIXME: what about ppc64 and s390x?" indicating that the support for PowerPC(ppc64) might still be incomplete.
Can we confirm that the new string implementation in Swift 4.2 has complete support for PowerPC(ppc64)?
No to throw a wrench in the works, but String's implementation changed again for Swift 5 and master, where it will be ABI stable and not significantly changed in the future.
Comment by Sarvesh Tamba (JIRA)
Thanks Michael for replying, I suppose the 'No to throw a wrench in the works' in your reply is a confirmation that the new string implementation in Swift 4.2 isn't supported for PowerPC(ppc64le) yet. Please correct me if that's not the case.
Current Swift 5.0 implementation also fails at the same step as Swift 4.2. Still optimistic and still hanging on hoping to get some help! 🙂
I'll try to merge https://github.com/apple/swift/pull/16425 soon. Can you try cherry-picking 9a96666ef8385b90686e5098ed12af1cf9db8277 on master and post your results?
Comment by Sarvesh Tamba (JIRA)
@milseman, I tried cherry-picking 9a96666ef8385b90686e5098ed12af1cf9db8277 on master and built both debug & release builds on PowerPC - ppc64le. Both builds completed successfully. However the swift binaries crash in both the instances. Attached are the core dumps and gdb backtraces for your reference.
Let me know if we are missing anything and I can try that out. Thanks once again for your help!
Program terminated with signal SIGSEGV, Segmentation fault.
#​0 0x00003fff967ff94c in std::atomic<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::load (this=0x8000203d20746e50,
__m=std::memory_order_consume) at /usr/lib/gcc/powerpc64le-linux-gnu/5.4.0/../../../../include/c++/5.4.0/atomic:235
235 __atomic_load(&_M_i, &tmp, __m);
(gdb) bt
#​0 0x00003fff967ff94c in std::atomic<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::load (this=0x8000203d20746e50,
__m=std::memory_order_consume) at /usr/lib/gcc/powerpc64le-linux-gnu/5.4.0/../../../../include/c++/5.4.0/atomic:235
#​1 0x00003fff967ffb1c in swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::increment (this=0x8000203d20746e50, inc=1)
at /root/swift-source/swift/include/swift/Runtime/../../../stdlib/public/SwiftShims/RefCount.h:696
#​2 0x00003fff967f92b8 in _swift_retain_ (object=0x8000203d20746e48) at /root/swift-source/swift/stdlib/public/runtime/HeapObject.cpp:300
#​3 0x00003fff967f9230 in swift::swift_retain (object=0x8000203d20746e48)
at /root/swift-source/swift/stdlib/public/runtime/HeapObject.cpp:294
#​4 0x00003fff968dc018 in swift_bridgeObjectRetain (object=0xee00203d20746e49)
at /root/swift-source/swift/stdlib/public/runtime/SwiftObject.mm:636
#​5 0x00003fff9664b8f8 in $ss13_StringObjectV17rawUncheckedValueABs6UInt64V_AEt_tcfC (bits=...)
at /root/swift-source/swift/stdlib/public/core/StringObject.swift:278
#​6 0x00003fff9664bb7c in $ss13_StringObjectV8rawValueABs6UInt64V_AEt_tcfC (bits=...)
at /root/swift-source/swift/stdlib/public/core/StringObject.swift:284
#​7 0x00003fff9663fecc in $ss13_StringObjectVyABs06_SmallA0VcfC (small=...)
at /root/swift-source/swift/stdlib/public/core/StringObject.swift:787
#​8 0x00003fff9662c5bc in $ss11_StringGutsVyABs06_SmallA0VcfC (smol=...) at /root/swift-source/swift/stdlib/public/core/StringGuts.swift:50
#​9 0x00003fff963908f4 in $sSS21_builtinStringLiteral17utf8CodeUnitCount7isASCIISSBp_BwBi1_tcfC (start=0x3fff93be009d, utf8CodeUnitCount=14,
isASCII=0) at /root/swift-source/swift/stdlib/public/core/String.swift:517
#​10 0x00003fff97dc029c in $s6REPL_0ySicfU_ ()
#​11 0x00003fff97dc0230 in main ()
#​12 0x000000001168c7a4 in llvm::MCJIT::runFunction (this=0x1001e43a960, F=0x1001e58de48, ArgValues=...)
at /root/swift-source/llvm/lib/ExecutionEngine/MCJIT/MCJIT.cpp:548
#​13 0x000000001169efd4 in llvm::ExecutionEngine::runFunctionAsMain (this=0x1001e43a960, Fn=0x1001e58de48,
argv=std::vector of length 5, capacity 5 = {...}, envp=0x0) at /root/swift-source/llvm/lib/ExecutionEngine/ExecutionEngine.cpp:471
#​14 0x000000001028e344 in REPLEnvironment::executeSwiftSource (this=0x3fffc3cfd480, Line=...,
CmdLine=std::vector of length 5, capacity 5 = {...}) at /root/swift-source/swift/lib/Immediate/REPL.cpp:946
#​15 0x00000000102848ac in REPLEnvironment::handleREPLInput (this=0x3fffc3cfd480, inputKind=(anonymous namespace)::REPLInputKind::SourceCode,
Line=...) at /root/swift-source/swift/lib/Immediate/REPL.cpp:1193
#​16 0x0000000010281f94 in swift::runREPL (CI=..., CmdLine=std::vector of length 5, capacity 5 = {...}, ParseStdlib=false)
at /root/swift-source/swift/lib/Immediate/REPL.cpp:1220
#​17 0x00000000101bc9c4 in performCompile (Instance=..., Invocation=..., Args=..., ReturnValue=@0x3fffc3cfe984: 0, observer=0x0, Stats=0x0)
at /root/swift-source/swift/lib/FrontendTool/FrontendTool.cpp:982
#​18 0x00000000101bbc14 in swift::performFrontend (Args=...,
Argv0=0x3fffc3d0f875 "/root/swift-source/build/Ninja-DebugAssert/swift-linux-powerpc64le/bin/swift",
MainAddr=0x100c61b0 <getExecutablePath[abi:cxx11](char const*)>, observer=0x0)
---Type <return> to continue, or q <return> to quit---
at /root/swift-source/swift/lib/FrontendTool/FrontendTool.cpp:1840
#​19 0x00000000100c7690 in run_driver (ExecName=..., argv=...) at /root/swift-source/swift/tools/driver/driver.cpp:122
#​20 0x00000000100c6b34 in main (argc_=7, argv_=0x3fffc3d027b8) at /root/swift-source/swift/tools/driver/driver.cpp:246
So a crash trying to retain the BridgeObject. That BridgeObject has the high bit set, so it should early exit in the runtime. Instead, the runtime has this code:
/// Return true iff the given BridgeObject is a tagged value.
static bool isBridgeObjectTaggedPointer(void *object) {
return (uintptr_t(object) & heap_object_abi::BridgeObjectTagBitsMask) != 0;
}
#endif
// Mask out the spare bits in a bridgeObject, returning the object it
// encodes.
///
/// Precondition: object does not encode a tagged pointer
static void* toPlainObject_unTagged_bridgeObject(void *object) {
return (void*)(uintptr_t(object) & ~unTaggedNonNativeBridgeObjectBits);
}
void *swift::swift_bridgeObjectRetain(void *object) {
#if SWIFT_OBJC_INTEROP
if (isObjCTaggedPointer(object) || isBridgeObjectTaggedPointer(object))
return object;
#endif
auto const objectRef = toPlainObject_unTagged_bridgeObject(object);
#if SWIFT_OBJC_INTEROP
if (!isNonNative_unTagged_bridgeObject(object)) {
swift_retain(static_cast<HeapObject *>(objectRef));
return object;
}
objc_retain(static_cast<id>(objectRef));
return object;
#else
swift_retain(static_cast<HeapObject *>(objectRef));
return object;
#endif
}
@mikeash @jckarter, the bridge object tagged check only happens on platforms with ObjC interop. If that's the case, how in the world is Linux working with small strings or even string literals, both of which use tagged bridge objects?
(minor note: we should assert it's not tagged in
toPlainObject_unTagged_bridgeObject
The only thing that happens after that on Linux is a call to swift_retain, which has its own early exit check for zero or negative values on 64-bit platforms. If we're deciding that the high half of address space is reserved on every 64-bit platform, we'll want to change the condition in isValidPointerForNativeRetain too.
So, IIRC, we have some options:
/// Returns true if the pointer passed to a native retain or release is valid.
/// If false, the operation should immediately return.
static inline bool isValidPointerForNativeRetain(const void *p) {
#if defined(__x86_64__) || defined(__arm64__) || defined(__aarch64__) || defined(_M_ARM64) || defined(__s390x__)
// On these platforms, except s390x, the upper half of address space is reserved for the
// kernel, so we can assume that pointer values in this range are invalid.
// On s390x it is theoretically possible to have high bit set but in practice
// it is unlikely.
return (intptr_t)p > 0;
#else
return p != nullptr;
#endif
}
To just be the greater-than-zero check.
Put in the early-exit even on platforms without ObjC interop
Is my understanding that you'd prefer #1? The downside is that we'd limit ourselves to platforms that don't use the high bit (at least for user space), which is probably fine. We can always pursue #2 in the unlikely event that matters.
#1 sounds good, with the caveat that we need to keep the p != nullptr
path for 32-bit. I accidentally rejected the top half of the 32-bit address space while I was making my earlier changes and the failures were quite interesting and surprisingly hard to trigger.
I suspect the cavalcade of architectures in the #if
may just be an attempt to say "if 64-bit" and PPC64 is an accidental omission.
The condition we need is "64-bit platforms where the top bit is reserved". So far that's all the ones we support, but the explicit list does force us to continue checking. Maybe we should have an #elif __POINTER_WIDTH__ == 64 #error
to make sure that they don't just fall into the 32-bit case?
That sounds good. Since this is so architecture-specific I wonder if we should just explicitly list all the 32-bit archs as well, then #error
on any unknown arch.
I thought the conclusion of https://github.com/apple/swift/pull/16425 was that we were unilaterally assuming that 56 bits ought to be enough for any 64-bit platform we care about, which should mean that we can always reserve the top bit in `isValidPointerForNativeRetain` on a 64-bit target. I would say we should do both #1 and #2, though, since it's non-obvious to follow the net behavior of the code otherwise.
If it's possible to unify the conditions under which we use SWIFT_ABI_DEFAULT_64BIT_SPARE_BITS_MASK and reserve negative retainable pointer values, that'd be nice at minimum.
Comment by Sarvesh Tamba (JIRA)
Thanks a lot guys for the inputs. Here is what I tried:-
Updated the platform check with following changes in "/swift/stdlib/public/runtime/HeapObject.cpp" in "static inline bool isValidPointerForNativeRetain(const void *p)" function along with cherry pick 9a96666ef8385b90686e5098ed12af1cf9db8277(I guess this is already merged in the master branch by now):-
#if defined(x86_64) || defined(arm64) || defined(aarch64) || defined(M_ARM64) || defined(s390x) || defined(powerpc64) || defined(ppc) || defined(PPC) || defined(LITTLE_ENDIAN) || defined(powerpc64le) || defined(ppc64le) || defined(PPC64LE_)
(Note:- Need to revisit this check and keep only the appropriate ones, put all of the above to save on the build times, please excuse 🙂 )
With this the release build got successfully built and swift was able to compile simple swift code correctly:-
root@swift42-debugub1604:\~# ll /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swift
-rwxr-xr-x 1 root root 129477384 Nov 30 06:26 /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swift*
root@swift42-debugub1604:\~# ll /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swiftc
lrwxrwxrwx 1 root root 5 Nov 30 06:26 /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swiftc -> swift*
root@swift42-debugub1604:\~# /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swift
You are running Swift's integrated REPL, ***
intended for compiler and stdlib ***
development and testing purposes only. ***
The full REPL is built as part of LLDB. ***
Type ':help' for assistance. ***
(swift) 1+1
// r0 : Int = 2
(swift) print("Hello World")
Hello World
(swift)
root@swift42-debugub1604:\~# cat testswift.swift
/* My first program in Swift 4 */
var myString = "Hello, World!"
print(myString)
root@swift42-debugub1604:\~# /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swift testswift.swift
Hello, World!
root@swift42-debugub1604:\~# /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swiftc testswift.swift
root@swift42-debugub1604:\~# ./testswift
Hello, World!
Investigating if complex code like import Foundation or other packages work with this. Also trying to build the tool chain.
Comment by Sarvesh Tamba (JIRA)
Hi All,
I was finally able to build the swift toolchain successfully on PowerPC(ppc64le) using "utils/build-toolchain" on master branch.
With this I am able to import packages as well:-
root@swift42-debugub1604:\~# cat testfoundation.swift
//: Playground - noun: a place where people can play
import Foundation
var str = "Hello, playground"
print(str)
root@swift42-debugub1604:\~# /root/swift-source/swift/swift-nightly-install/usr/bin/swiftc testfoundation.swift
root@swift42-debugub1604:\~# ./testfoundation
Hello, playground
root@swift42-debugub1604:\~# /root/swift-source/swift/swift-nightly-install/usr/bin/swift testfoundation.swift
Hello, playground
root@swift42-debugub1604:\~# /root/swift-source/swift/swift-nightly-install/usr/bin/swift
Welcome to Swift version 5.0-dev (LLVM 06a544889f, Clang 28ead70f59, Swift 792a50ec89).
Type :help for assistance.
1> 1+1
$R0: Int = 2
2> print("hello world")
hello world
3> import Foundation
4> import Dispatch
5>
Following are the final set of changes:
1.) Updated the platform check with following changes in "swift/stdlib/public/runtime/HeapObject.cpp" in "static inline bool isValidPointerForNativeRetain(const void *p)" function
#if defined(x86_64) || defined(arm64) || defined(aarch64) || defined(M_ARM64) || defined(s390x) || defined(powerpc64) || defined(ppc) || defined(PPC) || defined(LITTLE_ENDIAN_)
2.) Updated the platform check with following changes in "llvm/include/llvm/Support/Threading.h" to use LLVM's implementation of call_once(std::call_once is probably buggy on PowerPC platform)
!(defined(NetBSD) || defined(OpenBSD) || defined(ppc)) || (defined(PPC) && defined(LITTLE_ENDIAN)))
3.) Update the enum - "public enum Arch" to change "case ppc64le" to case powerpc64le
Note:- Cherry pick 9a96666ef8385b90686e5098ed12af1cf9db8277 - not required since already present in the code stream for master branch.
Would highly appreciate if someone can review and confirm these changes before I can formally raise a PR for them.
Thanks once again!
Sarvesh
I think PRs are the best way for us to review changes.
Comment by Sarvesh Tamba (JIRA)
Raised the following PRs:-
swift:-
https://github.com/apple/swift/pull/21038
swift-llvm:-
https://github.com/apple/swift-llvm/pull/128
swift-package-manager(swiftpm):-
https://github.com/apple/swift-package-manager/pull/1906
Comment by Sarvesh Tamba (JIRA)
I also invoked the build-toolchain to run the tests as well :-
utils/build-toolchain srtbundle --test
Following is the current status of the tests which are failing so far:-
4 warning(s) in tests.
Testing Time: 1774.53s
********************
Failing Tests (19):
Swift(linux-powerpc64le) :: ClangImporter/cfuncs_parse.swift
Swift(linux-powerpc64le) :: Driver/sanitizers.swift
Swift(linux-powerpc64le) :: Driver/fuzzer.swift
Swift(linux-powerpc64le) :: IRGen/class_resilience_objc.swift
Swift(linux-powerpc64le) :: IRGen/big_types_corner_cases.swift
Swift(linux-powerpc64le) :: IRGen/clang_inline_opt.swift
Swift(linux-powerpc64le) :: IRGen/errors.sil
Swift(linux-powerpc64le) :: IRGen/objc_simd.sil
Swift(linux-powerpc64le) :: IRGen/objc_properties_jit.swift
Swift(linux-powerpc64le) :: IRGen/pic.swift
Swift(linux-powerpc64le) :: Index/Store/output-failure.swift
Swift(linux-powerpc64le) :: Interpreter/generic_casts.swift
Swift(linux-powerpc64le) :: ParseableInterface/ModuleCache/force-module-loading-mode-archs.swift
Swift(linux-powerpc64le) :: ParseableInterface/ModuleCache/force-module-loading-mode-framework.swift
Swift(linux-powerpc64le) :: ParseableInterface/ModuleCache/force-module-loading-mode.swift
Swift(linux-powerpc64le) :: Runtime/linux-fatal-backtrace.swift
Swift(linux-powerpc64le) :: Sanitizers/tsan.swift
Swift(linux-powerpc64le) :: remote-run/upload-stderr.test-sh
Swift(linux-powerpc64le) :: Sanitizers/witness_table_lookup.swift
Expected Passes : 10116
Expected Failures : 50
Unsupported Tests : 1341
Unexpected Failures: 19
Attached are the failure details of each of the failing tests.
swift-test-failures-ppc64le.txt
Can anyone confirm if these test cases are supported for PowerPC64LE?
Comment by Sarvesh Tamba (JIRA)
Around 5 tests fail with "FileCheck error: '-' is empty."
Tried adding "-allow-empty" to the FileCheck command line: build/buildbot_linux/llvm-linux-powerpc64le/bin/FileCheck. Still the tests fails on subsequest steps.
The failing tests are:-
swift/test/Driver/fuzzer.swift
swift/test/IRGen/objc_properties_jit.swift
swift/test/Index/Store/output-failure.swift
swift/test/Interpreter/generic_casts.swift
swift/test/remote-run/upload-stderr.test-sh
Is this still an issue? I don't think this should be on me.
Attachment: Download
Environment
ppc64le running Ubuntu 16.04 distribution.Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | Bug | |Assignee | None | |Priority | Medium | md5: e8e5748ebca1db8526bf68baa425ac9aIssue Description:
I was rebuilding swift to validate my ppc64le related changes done in Swift and related repositories. I am observing crashes during swift build. The crashes are happening in swift/stdlib/public/core/Builtin.swift file and I was able to trace the cause to a new addition made under commit 3be2faf5d320000b2fae7049dc2400eb1dd4dcbf which seems to be a new implementation for 64-bit StringGuts.
H
ere is the stack trace I am seeing in the console:
— bootstrap: note: building runtime v4 target: PackageDescription4: Compile Swift Module ‘PackageDescription’ (9 sources) Link PackageDescription — bootstrap: note: building self-hosted ‘swift-build’: env SWIFT_EXEC=/root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/powerpc64le-unknown-linux/release/swiftc SWIFTPM_BUILD_DIR=/root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/powerpc64le-unknown-linux/release/swift-build-stage1 --disable-sandbox -Xlinker -rpath -Xlinker $ORIGIN/…/lib/swift/linux -Xlinker -L -Xlinker /root/latest/swift-source/buildbot_incremental/foundation-linux-powerpc64le/Foundation -Xlinker -rpath -Xlinker /root/latest/swift-source/buildbot_incremental/foundation-linux-powerpc64le/Foundation -Xswiftc -I/root/latest/swift-source/buildbot_incremental/foundation-linux-powerpc64le/Foundation -Xswiftc -I/root/latest/swift-source/buildbot_incremental/foundation-linux-powerpc64le/Foundation/usr/lib/swift -Xlinker -L -Xlinker /root/latest/swift-source/buildbot_incremental/xctest-linux-powerpc64le -Xlinker -rpath -Xlinker /root/latest/swift-source/buildbot_incremental/xctest-linux-powerpc64le -Xswiftc -I/root/latest/swift-source/buildbot_incremental/xctest-linux-powerpc64le -Xlinker -L/root/latest/swift-source/buildbot_incremental/libdispatch-linux-powerpc64le/src/.libs -Xswiftc -I/root/latest/swift-source/buildbot_incremental/libdispatch-linux-powerpc64le/src -Xswiftc -I/root/latest/swift-source/buildbot_incremental/libdispatch-linux-powerpc64le/src/swift -Xswiftc -I/root/latest/swift-source/swift-corelibs-libdispatch -Xcc -fblocks -Xswiftc -enable-testing --configuration release --build-tests Fatal error: file /root/latest/swift-source/swift/stdlib/public/core/Builtin.swift, line 466 Current stack trace: 0 libswiftCore.so 0x00003fff83344f90 _swift_stdlibreportFatalErrorInFile + 276 1 libswiftCore.so 0x00003fff83288b28 + 5933864 2 libswiftCore.so 0x00003fff8328859c + 5932444 3 libswiftCore.so 0x00003fff82e944f8 + 1787128 4 libswiftCore.so 0x00003fff832888b8 + 5933240 5 libswiftCore.so 0x00003fff832884f4 + 5932276 6 libswiftCore.so 0x00003fff82e944f8 + 1787128 7 libswiftCore.so 0x00003fff831cd3b4 + 5166004 8 libswiftCore.so 0x00003fff831cd214 + 5165588 9 libswiftCore.so 0x00003fff82e944f8 + 1787128 10 libswiftCore.so 0x00003fff82e936c0 _fatalErrorMessage(_::file:line:flags:) + 212 11 libswiftCore.so 0x00003fff8317b790 + 4831120 12 libswiftCore.so 0x00003fff83193840 + 4929600 13 libswiftCore.so 0x00003fff8312e308 + 4514568 14 libswiftCore.so 0x00003fff832f794c + 6388044 15 libstdc++.so.6 0x00003fff81bc2f00 once_proxy + 52 16 libpthread.so.0 0x00003fff81e322f4 + 74484 17 libswiftCore.so 0x00003fff832f7850 swift_once + 120 18 libswiftCore.so 0x00003fff8312e380 static CommandLine.arguments.getter + 52 19 swift-build-stage1 0x00000000258dd360 + 316256 20 libc.so.6 0x00003fff8181309c + 143516 21 libc.so.6 0x00003fff818131e0 libc_start_main + 184 — bootstrap: error: build failed with exit status -5 utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting
I tried to start swift build in debug mode, but my VM does not have enough resources to complete the build task.