On Tue, Apr 12, 2016 at 9:32 AM, Saleem Abdulrasool <compn...@compnerd.org> wrote:
> On Monday, April 11, 2016, Joe Groff <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 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
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
