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

[Joe Groff]

> On Dec 10, 2015, at 9:29 AM, William Dillon <william at housedillon.com> wrote:
> 
> Yep.  I see that are a few of those in there (1700 and change).  When it comes to linking and ELF, I am fumbling in the dark a bit.  With the hope of getting some context, I decided to see whether R_ARM_REL32 is used in any other shared libraries in the system; it is not.  It seems as though R_ARM_REL32 is not appropriate for use in dynamic libraries, but the generated swift executables are trying to use it that way.  I thought I remembered that swift binaries are only capable of static liking for the time being, is that true?  Could the problem be as simple as the compiler that I built on ARM is trying to emit executables expecting dynamic linking when that’s not supported yet?

We use relative references to symbols in the conformance table to avoid the need for the dynamic linker to eagerly resolve relocations. These should be wholly internal to the image, though, and resolvable by the static linker. I'm not sure why they'd persist to dynamic linking time like this.

-Joe

> I’m building the debug variant (I’ve been using release due to the memory requirements of linking debug) now to see if it does the same thing.  I don’t understand why the arch. change would cause differences here.
> 
> By the way, that pull request for module.map looks perfect.  I’ll have to wait for it to merge in before I can prepare any kind of pull request of my own.  I think that is the only thing that breaks other builds that I don’t know how to fix on my own.
> 
> Thanks,
> - Will
> 
>> On Dec 9, 2015, at 8:23 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>> 
>> Here's a relevant line (there are lots, this is just one instance):
>> 
>> 003a91cc  0015d403 R_ARM_REL32       003af914   _TMps13GeneratorType
>> 
>> _TMps13GeneratorType ---> protocol descriptor for Swift.GeneratorType
>> 
>> Dmitri
>> 
>> On Wed, Dec 9, 2015 at 7:25 PM, William Dillon <william at housedillon.com> wrote:
>>> I’m looking at that pull request currently, thanks for the link.
>>> 
>>> Here is the output of readelf -r for libswiftcore, test.swift (as compiled)
>>> and test.swift.
>>> 
>>> Thanks for looking into this!
>>> - Will
>>> 
>>> 
>>> 
>>> On Dec 9, 2015, at 7:14 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>> 
>>> On Wed, Dec 9, 2015 at 7:05 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>> 
>>> On Wed, Dec 9, 2015 at 3:05 PM, William Dillon via swift-dev
>>> <swift-dev at swift.org> wrote:
>>> 
>>> 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).
>>> 
>>> 
>>> Did you try https://github.com/apple/swift/pull/282 ?
>>> 
>>> 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.
>>> 
>>> 
>>> +John for this error.
>>> 
>>> 
>>> It would be also helpful if you could find which code contains these
>>> relocations.  Try 'objdump -R libswiftCore.so' or 'readelf -r'.
>>> 
>>> Dmitri
>>> 
>>> --
>>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
>