[swift-dev] COFF indirect addressing and protocol conformance tables ABI issues

[Saleem Abdulrasool]

On Sat, Jul 9, 2016 at 4:07 PM, Saleem Abdulrasool <compnerd at compnerd.org>
wrote:

> On Wed, Jul 6, 2016 at 9:43 AM, John McCall <rjmccall at apple.com> wrote:
>
>> On Jul 6, 2016, at 7:33 AM, Saleem Abdulrasool <compnerd at compnerd.org>
>> wrote:
>> On Tue, Jul 5, 2016 at 6:28 PM, John McCall <rjmccall at apple.com> wrote:
>>
>>> On Jul 5, 2016, at 5:56 PM, Saleem Abdulrasool <compnerd at compnerd.org>
>>> wrote:
>>> On Tue, Jul 5, 2016 at 10:30 AM, John McCall <rjmccall at apple.com> wrote:
>>>
>>>> > On Jul 3, 2016, at 2:40 PM, Saleem Abdulrasool <compnerd at compnerd.org>
>>>> wrote:
>>>> > Hello again,
>>>> >
>>>> > I come bearing more problems :-).
>>>> >
>>>> > I seem to have found another point in the ABI which prevents an easy
>>>> port of swift to Windows without an emulation layer underneath.  This time
>>>> it deals with the protocol conformance table.  The table is constructed
>>>> with a direct reference to protocol.  However, because the protocol lies in
>>>> an external module, this ends up being a problem as it must be indirectly
>>>> addressed.
>>>> >
>>>> > There is a workaround in place for generating a GOT equivalent entry,
>>>> however, that still doesnt indirect through the pointer, which needs to be
>>>> done to address the executable model on Windows.
>>>>
>>>> Is it not possible to emit the GOT equivalent entry as a reference to
>>>> the appropriate entry in the import lookup table?
>>>
>>>
>>> I had tried that, but it would still just be a constant reference to the
>>> value rather than the synthetic.  Perhaps I am misunderstanding something?
>>>
>>>
>>> I don't know what you mean.  I assume this is the reference to the
>>> protocol structure from the global protocol-conformances list.  This
>>> reference is a relative offset, either directly to the protocol structure
>>> or indirectly to a global containing a pointer to an external protocol
>>> structure.  PE's import lookup table is an array of pointers to external
>>> objects.
>>>
>>
>> Exactly, in the case that identified the issue, it is _TMps12OutputStream
>>
>>
>>> I could easily believe that COFF doesn't allow us to express a relative
>>> offset to an entry in the import lookup table.
>>>
>>
>> I don't think that there is any way to represent that in IR, and I don't
>> know if COFF allows us to encode such a thing.  I will see if I can
>> construct an object file/library and see if we can get away with that.
>>
>>
>> The way to represent it in IR is using the same private unnamed_addr
>> representation that we special-case for ELF/Mach-O.  I guess it would be a
>> mandatory transformation for COFF.
>>
>> But if it's not representable in COFF, that's pretty conclusive.
>>
>
> I did look into this.  It is, as I suspected, not possible to represent an
> offset to the value in the ILT or IAT.
>
>
This seems to be the only blocking issue for the Windows port.  There is a
minor build wrinkle that needs to be worked out, but everything else seems
to be more or less ready for enabling a Windows port.


> John.
>>
>>
>>
>>>  However, it sounds like you think this needs to be *doubly* indirected,
>>> i.e. the conformance list needs to be a relative offset to a variable
>>> containing a pointer to a variable containing a pointer to the import
>>> lookup table.  I'm not sure why that would be.
>>>
>> John.
>>>
>>
>>
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>>
>>
>>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>



-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160713/41e91f2f/attachment.html>