[swift-dev] swift (ABI) and Windows

[Saleem Abdulrasool]

Hi,

I was playing around with the idea of swift and Windows since there are
some interesting differences between COFF/PE and (ELF and MachO).

PE/COFF does not directly address symbols in external modules
(DSOs/dylibs/DLLs).  Instead, there is an indirect addressing model (thunks
in Windows parlance).  Fortunately, LLVM has a nice way to model this:
GlobalValues have an associated "DLLStorageClass" which indicates whether
something is "imported" (provided by an external module), "exported"
(provided to external modules), or "default" (everything else).

Adjusting the IRGen to correctly annotate this part of the semantics should
get us part of the way to supporting swift on PE/COFF.

The thing to consider with this is that the DLL storage class is dependent
on how the module(s) are being built.  For example, something may change
from the exported storage to default if being built into a static library
rather than a shared object and is not meant to be re-exported.

Part of this information really needs to be threaded from the build system
so that we know whether a given SIL module is external or internal.

Given that this would potentially effect ABI stability, it seems like this
is a good time to tackle it so that we can push this into the resilience
work that is being done for swift 3.

I would appreciate any pointers and suggestions as to how to best go about
handling this.

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