[swift-dev] Relative Pointers and Windows ARM

[Joe Groff]

> On May 19, 2016, at 9:07 AM, John McCall via swift-dev <swift-dev at swift.org> wrote:
> 
>> On May 18, 2016, at 1:51 PM, Saleem Abdulrasool <compnerd at 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; }

I'm not familiar with Windows ARM, but if image loading works like Windows on Intel, then PIC isn't a thing—everything is compiled for a fixed address, and the kernel brute-force slides all the addresses at load time if it can't map an exe or dll at its preferred address.

-Joe