> On May 19, 2016, at 5:39 PM, Saleem Abdulrasool <compn...@compnerd.org> wrote:
> On Thu, May 19, 2016 at 9:07 AM, John McCall <rjmcc...@apple.com
> <mailto:rjmcc...@apple.com>> wrote:
> > On May 18, 2016, at 1:51 PM, Saleem Abdulrasool <compn...@compnerd.org
> > <mailto:compn...@compnerd.org>> wrote:
> > 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.
>
> You can build PIC on Windows ARM, right? How does Microsoft compile this:
>
> static int x;
> int *get_x_addr() { return &x; }
>
> It will generate what they call a based relocation, relying on the DLL
> sliding to adjust for the load at an address other than the preferred base
> address.
Okay, so an absolute address and metadata to do a fix-up, i.e. not PIC. Score
one for Joe.
I guess it's probably not reasonable to assume that IMAGE_REL_ARM_BRANCH24 will
just work. :) 16M is not really a reasonable max image size anyway.
Well, if we wanted to be adventurous, we could ask Microsoft to add an
IMAGE_REL_ARM_REL32 relocation in a future toolchain. What we're asking of the
ELF and Mach-O linkers isn't all that much less ridiculous... In the meantime,
yeah, we should probably just switch to absolute addressing; it should be easy
enough to generalize that in the metadata scheme.
John.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
