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

[Dmitri Gribenko]

On Mon, Dec 14, 2015 at 5:57 PM, William Dillon via swift-dev
<swift-dev at swift.org> wrote:
> I’m still stuck on this after a while, but I’ve been paying attention to other discussions (specifically the FreeBSD port), as well as reading tons of code.  One thing I noticed while writing up my observations on my blog http://www.housedillon.com/?p=2267 is that in stdlib/public/runtime/CMakeLists.txt there is a FIXME that seems relevant:
>
> foreach(sdk ${SWIFT_CONFIGURED_SDKS})
>   if("${sdk}" STREQUAL "LINUX" OR "${sdk}" STREQUAL "FREEBSD")
>     foreach(arch ${SWIFT_SDK_${sdk}_ARCHITECTURES})
>       set(arch_subdir "${SWIFT_SDK_${sdk}_LIB_SUBDIR}/${arch}")
>
>       # FIXME: We will need a different linker script for 32-bit builds.
>       configure_file(
>           "swift.ld" "${SWIFTLIB_DIR}/${arch_subdir}/swift.ld" COPYONLY)
>
>       swift_install_in_component(compiler
>           FILES "swift.ld"
>           DESTINATION "lib/swift/${arch_subdir}")
>
>     endforeach()
>   endif()
> endforeach()
>
>
> I went ahead and added a conditional for arm, and split swift.ld into swift_64.ld and swift_32.ld:

The reason why I left that comment there is that the linker script
adds a size field to the protocol conformance section, and I thought
that the 32-bit system should have the size be a 32-bit value, so that
would be the difference.

But the source always loads a 64-bit quantity from the section, so the
FIXME is stale:

  // Extract the size of the conformances block from the head of the section
  auto conformancesSize = *reinterpret_cast<const uint64_t*>(conformances);

> I decided to go ahead and check the same conformances that Dmitri and Davide investigated:
>
> $ objdump -t libswiftCore.so | grep conformances
> 003b8ebc l    d  .swift2_protocol_conformances  00000000              .swift2_protocol_conformances
> 003b8ec4 l     O .swift2_protocol_conformances  00002f50              l_protocol_conformances
> 003b8ebc g       .swift2_protocol_conformances  00000000              .swift2_protocol_conformances_start
>
> $ objdump -s -j .swift2_protocol_conformances libswiftCore.so |head -n 10
>
> libswiftCore.so:     file format elf32-littlearm
>
> Contents of section .swift2_protocol_conformances:
>  3b8ebc 542f0000 00000000 00000000 00000000  T/..............
>  3b8ecc 00000000 04000000 00000000 00000000  ................
>  3b8edc 00000000 04000000 00000000 00000000  ................
>  3b8eec 00000000 04000000 00000000 00000000  ................
>  3b8efc 00000000 04000000 00000000 00000000  ................
>  3b8f0c 00000000 04000000 00000000 00000000  ................
>
> And that seems OK based on Dmitri’s basic description of how it works.

Yes, this looks correct to me.

>
> Paradoxically, I also added a print (and eventually an exit()) to _addImageProtocolConformances() to see if it’s ever run.  I don’t believe it is:
>
> $ swiftc test.swift
> <unknown>:0: error: unable to load standard library for target 'armv7l-unknown-linux-gnueabihf'
> $ swiftc -target arm-unknown-linux-gnueabihf test.swift
> $ ./test
> ./test: error while loading shared libraries: /mnt/build/build/Ninja-ReleaseAssert/swift-linux-arm/lib/swift/linux/libswiftCore.so: unexpected reloc type 0x03

The dynamic loader does not finish running, so the code does not even
get a chance to run.

> Are there any other paths that I should be following that you can think of?

I think it would make most sense to try to:

(1) figure out what part of the library code (on the LLVM IR level)
produces this illegal relocation (on the high level, e.g., "this
symbol", "this runtime data structure" etc.),

(2) provide a minimized LLVM IR example that produces the illegal relocation.

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>*/