[swift-dev] swift (ABI) and Windows

[Saleem Abdulrasool]

On Wed, Apr 6, 2016 at 11:18 AM, Jordan Rose <jordan_rose at apple.com> wrote:

> Hey, Saleem. How do you expect this to differ from normal symbol
> visibility? It seems to me that in a shared library, any public symbol is
> either exported or imported, depending on whether it has a definition, and
> any non-public symbol is default. (Unlike C, we expect to have sensible
> rules here.) I guess there's the difference between "a public symbol from
> elsewhere in this library" and "a public symbol from some other library".
> Is that it?
>

Well, there are four cases to consider:
- externally available: imported
- defined (and available for others): exported
- defined (statically): default -- won't even show up, so this is a no-op
- defined (non-statically defined for internal use): default

The thing is that there is no modeling for internal symbols which other
shared objects can use.  The closest thing you can do is anonymize the
symbol (so you don't have a name that you can call it by, but you have an
integral ID).

A public symbol from elsewhere in this library is treated as a local symbol
defined elsewhere in this library.  However, a public symbol from another
library is treated differently.  These get a local symbol which is
synthesized to perform the indirect addressing.  The symbol uses the form
__USER_LABEL_PREFIX__ ## _imp_ ## name.  This will contain the real address
or an indirect jump for the public symbol.

The difference between static and shared libraries seems unfortunate to
> have to expose to IRGen, but we may end up needing that anyway to handle
> Mach-O/ELF-style symbol visibility.
>

Yes, it is unfortunate, but sounds like it could end up being beneficial.


> Jordan
>
>
> > On Apr 6, 2016, at 10:21, Saleem Abdulrasool via swift-dev <
> swift-dev at swift.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.
> >
> > 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
> > _______________________________________________
> > swift-dev mailing list
> > swift-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
>
>


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