<div dir="ltr">Yes, I ran 'swift Hello.swift'. I didn't know there is MCJIT in that.<div>I'll ask and find the answer for it.</div><div><br></div><div>-Han Sangjin</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-11 7:14 GMT+09:00 Joe Groff <span dir="ltr"><<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On May 10, 2016, at 3:11 PM, Sangjin Han <<a href="mailto:tinysun.net@gmail.com">tinysun.net@gmail.com</a>> wrote:<br>
><br>
> Joe,<br>
><br>
> LLVM's MCJIT? Did you mean the REPL mode?<br>
<br>
</span>By immediate mode, do you mean "swift foo.swift", where the script is immediately compiled and executed? That also uses MCJIT.<br>
<span class=""><br>
><br>
> I'm not ready to ask a question or understand the answer about them. Maybe it takes some time for me to handle them.<br>
> Currently, I want to concentrate on the immediate mode, dynamic/static linking on Windows (MSVC).<br>
<br>
</span>I suspect that this is because of an LLVM bug in handling dllimport/export in JIT mode. Asking the LLVM list, you should at least be able to confirm this, and maybe get help from other LLVM users who've run into similar issues.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Joe<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> By the way, in Cygwin (although it uses similar ABI and the COFF format), immediate mode and dynamic linking worked without the dll import/export consideration, it was 'ld''s magic. The immediate mode in Cygwin does not work if dllimport is applied. (same to Windows(MSVC) )<br>
><br>
> I think we may consider for only MSVC, if the REPL in Cygwin works without dllimport consideration.<br>
><br>
> -Han Sangjin<br>
><br>
> 2016-05-10 2:06 GMT+09:00 Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>>:<br>
><br>
> > On May 7, 2016, at 4:01 PM, Sangjin Han <<a href="mailto:tinysun.net@gmail.com">tinysun.net@gmail.com</a>> wrote:<br>
> ><br>
> > Hi all,<br>
> ><br>
> > I merged Saleem's #2080 to my working branch, and did some experiment.<br>
> ><br>
> > I could compile easily Hello.swift with #2080 merged one.<br>
> ><br>
> > swiftc -c -o Hello.obj Hello.swift<br>
> > clang -o Hello.exe Hello.obj -llibswiftCore -llibswiftSwiftOnoneSupport -Wl,<some link options><br>
> ><br>
> > Without #2080, I should use the *.ll-modifying-trick. It is perfect in this example.<br>
> ><br>
> > But, we need the way to disable dllimport. The immediate mode did not work.<br>
><br>
> If it only affects immediate mode, this might be a problem with LLVM's MCJIT. I would recommend asking llvm-dev, cc-ing Lang Hames (<a href="mailto:lhames@apple.com">lhames@apple.com</a>), to see what the right thing to do to reference DLL exports from JIT code is.<br>
><br>
> -Joe<br>
><br>
> > swift Hello.swift<br>
> > LLVM ERROR: Program used external function '__imp_globalinit_33_1BDF70FFC18749BAB495A73B459ED2F0_func3' which could not be resolved!<br>
> ><br>
> > swift -O Hello.swift<br>
> > LLVM ERROR: Program used external function '__imp__swift_getExistentialTypeMetadata' which could not be resolved!<br>
> ><br>
> > It seems swift.exe call directly the function in the DLL without import library.<br>
> ><br>
> > The feature also needed when we link to static library.<br>
> ><br>
> > I don't know about the SIL, IR, so it is thankful someone tell me how to approach this problem.<br>
><br>
><br>
><br>
> ><br>
> > 2016-05-07 5:01 GMT+09:00 Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org">compnerd@compnerd.org</a>>:<br>
> > On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev <<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a>> wrote:<br>
> ><br>
> > > On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev <<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a>> wrote:<br>
> > ><br>
> > > Hi,<br>
> > ><br>
> > > 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.<br>
> > ><br>
> > > 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")'.<br>
> > ><br>
> > > 1) SWIFT_RUNTIME_EXPORT was not enough for dllexport.<br>
> > > Hello.obj needed defined in libswift*.dll<br>
> > > _swift_getExistentialTypeMetadata,<br>
> > > _TFs5printFTGSaP__9separatorSS10terminatorSS_T_,<br>
> > > _TMSS,<br>
> > > _TZvOs7Process5_argcVs5Int32,<br>
> > > swift_bufferAllocate, ....<br>
> > > Some of above are dllexported by the macro, but _T* are not. Maybe, it generated by swiftc.exe.<br>
> > > I used the utility 'dlltool.exe' from Cygwin/MinGW world. It extracts all symbols and generates 'allsymbol.def'.<br>
> > > With that .def, I could build the all-symbol-dllexported libswiftCore.dll.<br>
> > > (I'm hoping we can build it without this trick.)<br>
> ><br>
> > 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.<br>
> ><br>
> > <a href="https://github.com/apple/swift/pull/2080" rel="noreferrer" target="_blank">https://github.com/apple/swift/pull/2080</a> is a first cut attempt to do this.<br>
> ><br>
> ><br>
> > -Joe<br>
> > _______________________________________________<br>
> > swift-dev mailing list<br>
> > <a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Saleem Abdulrasool<br>
> > compnerd (at) compnerd (dot) org<br>
> ><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>