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

[William Dillon]

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.

Ideas?
Thanks!
- Will

> 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
>>>> x86_64?
>>> 
>>> 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.
> 
> -Joe
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev