> On Apr 26, 2016, at 8:43 AM, Saleem Abdulrasool <compn...@compnerd.org> wrote:
> On Tue, Apr 12, 2016 at 9:32 AM, Saleem Abdulrasool <compn...@compnerd.org
> <mailto:compn...@compnerd.org>> wrote:
> On Monday, April 11, 2016, Joe Groff <jgr...@apple.com
> <mailto:jgr...@apple.com>> wrote:
>
> > On Apr 11, 2016, at 3:19 PM, Saleem Abdulrasool via swift-dev
> > <swift-dev@swift.org <>> wrote:
> >
> > On Thu, Apr 7, 2016 at 2:12 PM, Saleem Abdulrasool <compn...@compnerd.org
> > <>> wrote:
> > On Wed, Apr 6, 2016 at 10:21 AM, Saleem Abdulrasool <compn...@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
> > <https://github.com/compnerd/apple-swift/tree/dllstorage> and created a
> > Pull Request at https://github.com/apple/swift/pull/2080
> > <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.
I think it's reasonable to assume that @_silgen_name is not being used for
objects that are external to the declaring module. That is, the implementation
model is that those declarations really are declaring a Swift function; it just
happens that the actual body (if not provided) is provided magically. That
should work for all the standard library use cases.
John.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
