[swift-dev] [SR-40] Port Swift to Arm progress / question
william at housedillon.com
Wed Dec 9 17:05:43 CST 2015
Nick was correct in noting that __muloti4 wasn’t needed on 32-bit platforms. I added another case to the preprocessor conditional for __muloti4, and specified __arm__ and __linux__ for mulodi4. The __multi3 and __divti3 references went away.
Then, I went on to the module.map file for bringing in the Glibc headers. I’m trying to think of a way to either remove the architecture specific paths to many of those libraries (they’re now x86_64-linux-gnu, but need to be arm-linux-gnueabihf for arm). I read the modules documentation at http://clang.llvm.org/docs/Modules.html and it doesn’t look like it’s possible to have conditionals in there. I’m considering whether it’s a good idea to preprocess that file in some way to fill them out with the correct paths in the build scripts. I went ahead and changed them all (breaking x86_64 for the time being).
At this point, the compiler and standard library are all built, and I think I have one final issue. In the testing suite, the binaries generated by the swift compiler don’t run. They’re emitting unexpected reloc type errors. It appears that reolc type 0x03 is R_ARM_REL32 which is not permitted for use with shared libraries:
CollectionOfOne.swift.tmp/a.out: error while loading shared libraries: /home/wdillon/build/Ninja-ReleaseAssert/swift-linux-armv7/lib/swift/linux/libswiftCore.so: unexpected reloc type 0x03
This also happens with small example swift programs that I’ve written for testing.
> On Dec 9, 2015, at 10:58 AM, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
>> On Dec 9, 2015, at 10:05 AM, Nick Wellnhofer via swift-dev <swift-dev at swift.org> wrote:
>> On 09/12/2015 18:55, Nick Wellnhofer via swift-dev wrote:
>>>> Is there a better way to get that symbol, and why wasn’t this a problem for
>>> AFAICS, this is a problem for x86_64 Linux. It's not a problem on Apple
>>> platforms, because there C++ binaries are linked with compiler-rt instead of
>>> the GCC runtime.
>> Ah, you probably meant why __mulodi4 isn't a problem on x86_64 Linux. I think that's because it's defined by the 64-bit GCC runtime. (clang on Linux uses the GCC runtime AFAIK.)
> Right, libgcc doesn't provide 128-bit integer entry points on 32-bit platforms, and doesn't provide the overflow-checking variant __muloti4 at all AFAIK.
> swift-dev mailing list
> swift-dev at swift.org
More information about the swift-dev