[swift-dev] swift (ABI) and Windows

[Saleem Abdulrasool]

On Monday, May 9, 2016, Joe Groff <jgroff at apple.com> wrote:

>
> > On May 9, 2016, at 7:19 PM, Saleem Abdulrasool <compnerd at compnerd.org
> <javascript:;>> wrote:
> >
> > On Sat, May 7, 2016 at 7:55 PM, Sangjin Han <tinysun.net at gmail.com
> <javascript:;>> wrote:
> > One more,
> >
> > I couldn't build the libswiftCore.dll which can be used for Hello.swift.
> At least one symbol _TMSS is not dllexported.
> > (But I could build the dll with dlltool.exe which make all symbols to be
> dllexported)
> >
> > To find out the reason, I built a Swift.ll instead of the Swift.obj for
> the libswiftCore.dll. The Swift.ll are built from many
> stdlib/public/core/*.swift and core/8/*.swift files, and about 50MB.
> >
> > In that file, I could find many dllexport symbols, like
> > @_TZvOs7Process5_argcVs5Int32 = dllexport global %Vs5Int32
> zeroinitializer, align 4
> > and Hello.ll uses them,
> > @_TZvOs7Process5_argcVs5Int32 = external dllimport global %Vs5Int32,
> align 4
> >
> > In the case of _TMSS, Hello.ll uses the same way,
> > @_TMSS = external dllimport global %swift.type, align 8
> > But, Swift.ll did not declared with dllexport.
> > @_TMSS = alias %swift.type, bitcast (i64* getelementptr inbounds (<{
> i8**, i64, i64, %swift.type*, i64 }>, <{ i8**, i64, i64, %swift.type*, i64
> }>* @_TMfSS, i32 0, i32 1) to %swift.type*)
> >
> > How we can make @_TMSS also has the dllexport?  Or any other solution ?
> >
> > Interesting.  Does changing the string type from struct to class help?
> Ill try to have a look at this.
>
> Did you handle the path that creates these llvm::GlobalAlias objects for
> type metadata when adding the dllimport/export attributes?


Ah, awesome, thanks for that hint.  That was indeed missing.  I suppose I
should audit a few more things.  I'll upload a new version shortly that
should take care of the dll storage on metadata.


> -Joe
>
> >
> >
> > -Han Sangjin
> >
> >
> >
> >
> > 2016-05-08 8:01 GMT+09:00 Sangjin Han <tinysun.net at gmail.com
> <javascript:;>>:
> > Hi all,
> >
> > I merged Saleem's #2080 to my working branch, and did some experiment.
> >
> > I could compile easily Hello.swift with #2080 merged one.
> >
> >   swiftc -c -o Hello.obj Hello.swift
> >   clang -o Hello.exe Hello.obj -llibswiftCore
> -llibswiftSwiftOnoneSupport -Wl,<some link options>
> >
> > Without #2080, I should use the *.ll-modifying-trick. It is perfect in
> this example.
> >
> > But, we need the way to disable dllimport. The immediate mode did not
> work.
> >
> >   swift Hello.swift
> >   LLVM ERROR: Program used external function
> '__imp_globalinit_33_1BDF70FFC18749BAB495A73B459ED2F0_func3' which could
> not be resolved!
> >
> >   swift -O Hello.swift
> >   LLVM ERROR: Program used external function
> '__imp__swift_getExistentialTypeMetadata' which could not be resolved!
> >
> > It seems swift.exe call directly the function in the DLL without import
> library.
> >
> > The feature also needed when we link to static library.
> >
> > I don't know about the SIL, IR, so it is thankful someone tell me how to
> approach this problem.
> >
> >
> > 2016-05-07 5:01 GMT+09:00 Saleem Abdulrasool <compnerd at compnerd.org
> <javascript:;>>:
> > On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev <
> swift-dev at swift.org <javascript:;>> wrote:
> >
> > > On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev <
> swift-dev at swift.org <javascript:;>> wrote:
> > >
> > > Hi,
> > >
> > > I made an experimental MSVC port. Of cause, dllimport/dllexport and
> the driver for linking and many other part is not implemented. But dynamic
> linking was possible with some trick.
> > >
> > > I think it is useful for designing, my observation about the
> experimental building of libswiftCore.dll, libswiftSwiftOnoneSupport.dll
> and linking of Hello.exe - its source has only 'print("Hello")'.
> > >
> > > 1) SWIFT_RUNTIME_EXPORT was not enough for dllexport.
> > >   Hello.obj needed defined in libswift*.dll
> > >     _swift_getExistentialTypeMetadata,
> > >     _TFs5printFTGSaP__9separatorSS10terminatorSS_T_,
> > >     _TMSS,
> > >     _TZvOs7Process5_argcVs5Int32,
> > >     swift_bufferAllocate, ....
> > >   Some of above are dllexported by the macro, but _T* are not. Maybe,
> it generated by swiftc.exe.
> > >   I used the utility 'dlltool.exe' from Cygwin/MinGW world. It
> extracts all symbols and generates 'allsymbol.def'.
> > >   With that .def, I could build the all-symbol-dllexported
> libswiftCore.dll.
> > >   (I'm hoping we can build it without this trick.)
> >
> > The _T symbols are emitted by the Swift compiler. You should modify
> swiftc's IRGen to generate public symbols with LLVM's "dllexport" storage
> class when targeting Windows.
> >
> > https://github.com/apple/swift/pull/2080 is a first cut attempt to do
> this.
> >
> >
> > -Joe
> > _______________________________________________
> > swift-dev mailing list
> > swift-dev at swift.org <javascript:;>
> > https://lists.swift.org/mailman/listinfo/swift-dev
> >
> >
> >
> > --
> > 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/20160510/a57f002f/attachment.html>