[swift-dev] swift (ABI) and Windows

[Saleem Abdulrasool]

On Thu, Apr 7, 2016 at 2:12 PM, Saleem Abdulrasool <compnerd at compnerd.org>
wrote:

> On Wed, Apr 6, 2016 at 10:21 AM, Saleem Abdulrasool <compnerd at compnerd.org
> > wrote:
>
>> 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.
>>
>
> To the DLL Storage semantics support, Ive taken a quick first stab at it.
> Ive pushed the changes to
> https://github.com/compnerd/apple-swift/tree/dllstorage and created a
> Pull Request at https://github.com/apple/swift/pull/2080 .
>
> However, as I expected, this is going to cause problems for building some
> of the core libraries.  In particular, there are mismatches between what
> gets compiled and is desired.  The swiftStubs and swiftRuntime are
> statically compiled and then merged into swiftCore.  There is also the
> concern of the the support modules (e.g. Platform).  If there are stubs
> that are being used (e.g. via _silgen_name) then there are issues with
> calculating the correct DLL storage for the associated global values.
>

Playing around with this, I was trying to special case the building of the
standard library (as the runtime will be statically linked into it, the
symbols that it is expecting to be externally available are actually
private linkage.  Not hacking up the compiler like this causes issues since
there are inverse dependencies (swiftCore gets dllimport interfaces from
swiftRuntime, which has dependencies on swiftCore).  The crux of the
problem is that we do not have a way to represent that in swift.

The easiest answer that seems to come to mind is to actually introduce an
attribute to indicate that an interface is part of a specific module and
assume that everything else is locally defined.  This would also
potentially allow us to handle things like @inline(always) @transparent
interfaces which get imported to ensure that a static inline function is
given local visibility rather than a DLL Import storage.

Unfortunately, I believe that currently Im stuck as I do not have a good
way to determine what type of dll storage class a symbol should be given
(since currently, theres no way to determine if we will have a symbol
available locally or not when actually linking).


> It seems to me, at least initially, that we need a way to treat
> SwiftModule as a container (a la llvm::Module) and indicate which of the
> TopLevelDecls are meant to be a single "module" (DSO, DLL, whatever you
> want to call it) so that we can properly track the DLL storage associated
> with them.  Am I confusing something there?
>
> Is there a preference on a means to handle this?
>
>
>> 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
>>
>
>
>
> --
> 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/20160411/7bb62f72/attachment.html>