[swift-dev] Relative Pointers and Windows ARM

[Saleem Abdulrasool]

Hi,

It seems that there are assumptions about the ability to create relative
address across sections which doesn't seem possible on Windows ARM.

Consider the following swift code:

final class _ContiguousArrayStorage<Element> { }

When compiled for Windows x86 (via swiftc -c -target i686-windows
-parse-as-library -parse-stdlib -module-name Swift -o Swift.obj
reduced.swift) it will generate the metadata pattern as:

    __TMPCs23_ContiguousArrayStorage:
      ...
      .long
__TMnCs23_ContiguousArrayStorage-(__MPCs23_ContiguousArrayStorage+128)
      ...

This generates a IMAGE_REL_I386_REL32 relocation which is the 32-bit
relative displacement of the target.

On Windows ARM (swiftc -c -target i686-windows -parse-pas-library
-parse-stdlib -module-name Swift -o Swift.obj reduced.swift) it will
generate similar assembly:

    _TMPCs23_ContiguousArrayStorage:
      ...
      .long
_TMnCs23_ContiguousArrayStorage-(_MPCs23_ContiguousArrayStorage+128)
      ...

However, this generates an IMAGE_REL_ARM_ADDR32 relocation which is the
32-bit VA of the target.  If the symbol are in the same section, it is
possible to get a relative value.  However, I don't really see a way to
generate a relative offset across sections.  There is no relocation in the
COFF ARM specification which provides the 32-bit relative displacement of
the target.  There are 20, 23, and 24 bit relative displacements designed
specifically for branch instructions, but none that would operate on
generic data.

Is there a good way to address this ABI issue?  Or perhaps do we need
something more invasive to support such targets?  Now, I might be
completely overlooking something simple that I didn't consider, so pointing
that out would be greatly appreciated as well.

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160518/8c209ca2/attachment.html>