<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On May 19, 2016, at 5:39 PM, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org" class="">compnerd@compnerd.org</a>> wrote:</div><div class=""><div dir="ltr" class="">On Thu, May 19, 2016 at 9:07 AM, John McCall <span dir="ltr" class=""><<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On May 18, 2016, at 1:51 PM, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org" class="">compnerd@compnerd.org</a>> wrote:<br class="">
> Hi,<br class="">
><br class="">
> It seems that there are assumptions about the ability to create relative address across sections which doesn't seem possible on Windows ARM.<br class="">
><br class="">
> Consider the following swift code:<br class="">
><br class="">
> final class _ContiguousArrayStorage<Element> { }<br class="">
><br class="">
> 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 class="">
><br class="">
> __TMPCs23_ContiguousArrayStorage:<br class="">
> ...<br class="">
> .long __TMnCs23_ContiguousArrayStorage-(__MPCs23_ContiguousArrayStorage+128)<br class="">
> ...<br class="">
><br class="">
> This generates a IMAGE_REL_I386_REL32 relocation which is the 32-bit relative displacement of the target.<br class="">
><br class="">
> 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 class="">
><br class="">
> _TMPCs23_ContiguousArrayStorage:<br class="">
> ...<br class="">
> .long _TMnCs23_ContiguousArrayStorage-(_MPCs23_ContiguousArrayStorage+128)<br class="">
> ...<br class="">
><br class="">
> 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 class="">
><br class="">
> 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 class="">
<br class="">
</span>You can build PIC on Windows ARM, right? How does Microsoft compile this:<br class="">
<br class="">
static int x;<br class="">
int *get_x_addr() { return &x; }</blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><div><br class=""></div></div>Okay, so an absolute address and metadata to do a fix-up, i.e. not PIC. Score one for Joe.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.<br class=""><div class=""><br class=""></div><div class="">John.</div></div></body></html>