On Wednesday, May 18, 2016, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 18, 2016, at 1:51 PM, Saleem Abdulrasool via swift-dev <<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-dev@swift.org')">swift-dev@swift.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> It seems that there are assumptions about the ability to create relative address across sections which doesn't seem possible on Windows ARM.<br>
><br>
> Consider the following swift code:<br>
><br>
> final class _ContiguousArrayStorage<Element> { }<br>
><br>
> 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:<br>
><br>
> __TMPCs23_ContiguousArrayStorage:<br>
> ...<br>
> .long __TMnCs23_ContiguousArrayStorage-(__MPCs23_ContiguousArrayStorage+128)<br>
> ...<br>
><br>
> This generates a IMAGE_REL_I386_REL32 relocation which is the 32-bit relative displacement of the target.<br>
><br>
> 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:<br>
><br>
> _TMPCs23_ContiguousArrayStorage:<br>
> ...<br>
> .long _TMnCs23_ContiguousArrayStorage-(_MPCs23_ContiguousArrayStorage+128)<br>
> ...<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
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</blockquote><div><br></div>Yeah, it would make interoperability harder. But, is there a loader for macho on Windows?<div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Joe</blockquote></div><br><br>-- <br>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org<br>