[swift-dev] Relative Pointers and Windows ARM
Saleem Abdulrasool
compnerd at compnerd.org
Wed May 18 20:01:56 CDT 2016
On Wednesday, May 18, 2016, Joe Groff <jgroff at apple.com> wrote:
>
> > On May 18, 2016, at 1:51 PM, Saleem Abdulrasool via swift-dev <
> swift-dev at swift.org <javascript:;>> 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.
>
> That's unfortunate. One possibly-crazy solution would be to use a
> different object format that does support the necessary relocations, such
> as LLVM's win32-macho target. That would forgo interoperability with
> non-LLVM toolchains, of course
Yeah, it would make interoperability harder. But, is there a loader for
macho on Windows?
-Joe
--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160518/234bad8a/attachment.html>
More information about the swift-dev
mailing list