[swift-dev] [SR-40] Port Swift to Arm progress / question
William Dillon
william at housedillon.com
Wed Dec 9 11:43:27 CST 2015
Sure enough, it’s all true.
__ssize_t is an int, added the preprocessor conditional, and we’re moving forward.
I have no intention of addressing every issue here, but there is another I have a question about while I’m at it. While linking Swift.o, there is an undefined reference to __mulodi4. I found that __muloti4 is copied from compiler-rt into Stubbs.cpp to avoid new dependencies on compiler-rt in linux. I went ahead and copied __mulodi4 into the same file after __muloti4, but that seems a little hack-y. Is there a better way to get that symbol, and why wasn’t this a problem for x86_64? (also, is this: typedef int di_int __attribute__ ((mode (DI))); an appropriate way to define di_int?)
Even with that hack, I’m still getting undefined references to __multi3 and __divti3.
Thanks!
- Will
> On Dec 9, 2015, at 3:42 AM, Nick Wellnhofer via swift-dev <swift-dev at swift.org> wrote:
>
> On 09/12/2015 05:50, Dmitri Gribenko via swift-dev wrote:
>> Try preprocessing the following program with 'clang -E' and check how the type
>> is defined:
>>
>> #include <unistd.h>
>> #include <sys/types.h>
>
> It's probably defined as `int` as it is on Linux i386:
>
> https://github.com/nwellnhof/swift/commit/1a5962c890e43f115fc5d629a7b2ec108e1f489a#diff-58073e2ae1d7149ac7f3fe3d32dff142
>
>> Use #if:
>>
>> #if defined(__linux__) && defined(__arm__)
>> ...
>> #else
>> ...
>> #endif
>
> I guess this only works on 32-bit and needs another check for 64-bit. Why isnt't `__swift_ssize_t` simply defined as `ssize_t`? This would avoid this kind of problems.
>
> Nick
>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
More information about the swift-dev
mailing list