<div dir="ltr">Would it be acceptable to make relative pointers optional, so we can pay the extra load-time cost on platforms where it&#39;s hard/undesirable to implement them?<div><br></div><div>cheers,<br>Tom</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, May 19, 2016 at 9:51 AM Joe Groff via swift-dev &lt;<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; On May 18, 2016, at 6:01 PM, Saleem Abdulrasool &lt;<a href="mailto:compnerd@compnerd.org" target="_blank">compnerd@compnerd.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wednesday, May 18, 2016, Joe Groff &lt;<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On May 18, 2016, at 1:51 PM, Saleem Abdulrasool via swift-dev &lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; It seems that there are assumptions about the ability to create relative address across sections which doesn&#39;t seem possible on Windows ARM.<br>
&gt; &gt;<br>
&gt; &gt; Consider the following swift code:<br>
&gt; &gt;<br>
&gt; &gt; final class _ContiguousArrayStorage&lt;Element&gt; { }<br>
&gt; &gt;<br>
&gt; &gt; 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>
&gt; &gt;<br>
&gt; &gt;     __TMPCs23_ContiguousArrayStorage:<br>
&gt; &gt;       ...<br>
&gt; &gt;       .long __TMnCs23_ContiguousArrayStorage-(__MPCs23_ContiguousArrayStorage+128)<br>
&gt; &gt;       ...<br>
&gt; &gt;<br>
&gt; &gt; This generates a IMAGE_REL_I386_REL32 relocation which is the 32-bit relative displacement of the target.<br>
&gt; &gt;<br>
&gt; &gt; 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>
&gt; &gt;<br>
&gt; &gt;     _TMPCs23_ContiguousArrayStorage:<br>
&gt; &gt;       ...<br>
&gt; &gt;       .long _TMnCs23_ContiguousArrayStorage-(_MPCs23_ContiguousArrayStorage+128)<br>
&gt; &gt;       ...<br>
&gt; &gt;<br>
&gt; &gt; 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&#39;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>
&gt; &gt;<br>
&gt; &gt; 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&#39;t consider, so pointing that out would be greatly appreciated as well.<br>
&gt;<br>
&gt; That&#39;s unfortunate. One possibly-crazy solution would be to use a different object format that does support the necessary relocations, such as LLVM&#39;s win32-macho target. That would forgo interoperability with non-LLVM toolchains, of course<br>
&gt;<br>
&gt; Yeah, it would make interoperability harder.  But, is there a loader for macho on Windows?<br>
<br>
Sorry, if it wasn&#39;t clear, I meant that you could use mach-o (or ELF, or any object format really) for .o and .a files. You&#39;d still link them into PE executables and DLLs.<br>
<br>
-Joe<br>
_______________________________________________<br>
swift-dev mailing list<br>
<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br>
</blockquote></div>