[swift-dev] [SR-40] Port Swift to Arm progress / question

William Dillon william at housedillon.com
Tue Dec 8 22:00:23 CST 2015

Hi all,

I’ve been working on trying to get Swift to compile on ARMv7 (armv7l specifically, not sure if other variants will work as well).  I’ve gotten pretty far, but I ran a cross an issue that has me a little confused.  For convenience, here’s the bug that has some of my messages in the comments: https://bugs.swift.org/browse/SR-40 <https://bugs.swift.org/browse/SR-40> and here’s my Github fork if you want to play along at home: https://github.com/hpux735/swift <https://github.com/hpux735/swift>  By the way, I’m compiling on an Nvidia tegra TK2 development board with 2GB of ram and a 25GB swapfile on an external SSD.  This brings native compile times down to reasonable levels.  I was compiling on the BeagleBone Black formerly, and that was painful (like over a day for LLVM).

So far, cmark and llvm compile just fine (no surprise there), and swift gets pretty far along.  The weird issue, which will certainly expose my weakness in C++ and large build systems, is that the swift_ssize_t doesn’t match ssize_t.  

[6/61] Building CXX object stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/Stubs.cpp.o
FAILED: /usr/bin/clang++   -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-stack-protector -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor -Werror=date-time -std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -O3  -Istdlib/public/stubs -I/home/wdillon/swift/stdlib/public/stubs -I/home/wdillon/swift/include -Iinclude -I/home/wdillon/build/Ninja-ReleaseAssert/llvm-linux-armv7/include -I/home/wdillon/llvm/include -I/home/wdillon/build/Ninja-ReleaseAssert/llvm-linux-armv7/tools/clang/include -I/home/wdillon/llvm/tools/clang/include -I/home/wdillon/cmark/src -I/home/wdillon/build/Ninja-ReleaseAssert/cmark-linux-armv7/src    -UNDEBUG  -fno-exceptions -fno-rtti  -Wglobal-constructors -Wexit-time-destructors -target arm-unknown-linux-gnueabihf -isysroot / -O2 -g0 -UNDEBUG -MMD -MT stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/LibcShims.cpp.o -MF "stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/LibcShims.cpp.o.d" -o stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/LibcShims.cpp.o -c /home/wdillon/swift/stdlib/public/stubs/LibcShims.cpp
/home/wdillon/swift/stdlib/public/stubs/LibcShims.cpp:24:1: error: static_assert failed "__swift_ssize_t is wrong"
static_assert(std::is_same<ssize_t, swift::__swift_ssize_t>::value,
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

Now, the sizes match (4 bytes each), but the std::is_same() function says no.  I grep’d the clang codebase for the definition of ssize_t, and it seems like it’s a ‘long’ whereas the swift_ssize_t is a 'long int’.  I looked into the LibcShims a bit, and the expectation is that the definition in the header is not universally correct, and will be checked:

// This declaration is not universally correct.  We verify its correctness for
// the current platform in the runtime code.
typedef long int __swift_ssize_t;

And it is thusly (in LibcShims.cpp):

static_assert(std::is_same<ssize_t, swift::__swift_ssize_t>::value, "__swift_ssize_t is wrong”);

What’s less clear is the mechanism with which I am to change this definition in a way that doesn’t mess-up other platforms.

Any thoughts and ideas are welcome!
- Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151208/c935b587/attachment.html>

More information about the swift-dev mailing list