On Sat, Jul 9, 2016 at 4:07 PM, Saleem Abdulrasool <compn...@compnerd.org> wrote:
> On Wed, Jul 6, 2016 at 9:43 AM, John McCall <rjmcc...@apple.com> wrote: > >> On Jul 6, 2016, at 7:33 AM, Saleem Abdulrasool <compn...@compnerd.org> >> wrote: >> On Tue, Jul 5, 2016 at 6:28 PM, John McCall <rjmcc...@apple.com> wrote: >> >>> On Jul 5, 2016, at 5:56 PM, Saleem Abdulrasool <compn...@compnerd.org> >>> wrote: >>> On Tue, Jul 5, 2016 at 10:30 AM, John McCall <rjmcc...@apple.com> wrote: >>> >>>> > On Jul 3, 2016, at 2:40 PM, Saleem Abdulrasool <compn...@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
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
