[swift-dev] swift (ABI) and Windows

[Saleem Abdulrasool]

On Tue, Apr 12, 2016 at 9:32 AM, Saleem Abdulrasool <compnerd at compnerd.org>
wrote:

> On Monday, April 11, 2016, Joe Groff <jgroff at apple.com> wrote:
>
>>
>> > On Apr 11, 2016, at 3:19 PM, Saleem Abdulrasool via swift-dev <
>> swift-dev at swift.org> wrote:
>> >
>> > 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?
>>
>> The runtime is linked as part of the standard library, and its ABI
>> interface should be exported from libswiftCore.dylib/so/dll like the
>> standard library's. We should already mark up the ABI entry points with the
>> SWIFT_RUNTIME_EXPORT and SWIFT_RUNTIME_STDLIB_INTERFACE macros. Is it not
>> sufficient to expand these macros to __dllexport?
>
>
> The definitions can be marked as __declspec(dllexport) but the compiler
> generated references need to be dllimport for the wrapped runtime functions
> (easy for the most part -- see my changes).  There's also the concern of
> stubs for the aliases (via silgen_name).  Those are defined externally with
> no indication that they are locally available and thus should have default
> rather than dllimport storage.  Similar things for standard library
> metadata (type, witness tables, etc).
>

A gentle reminder on this topic.  I would like to get something sorted out
so that we can try to get this resolved, preferably before the swift 3
release.


> -Joe
>
>
>
> --
> 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/20160426/a7177d65/attachment.html>