swift (ABI) and Windows

Development Compiler
21

I merged Saleem's recent #2080 in my repo, and tested the same.

Now I could build the libswiftCore.dll which can be used for Hello.swift.
No _TMSS errors were occurred.

Unfortunately, ATM, the runtime is compacted into the stdlib, which has

the small problem of making the stdlib have references to the runtime
functions as if it were being dynamically linked.

The linker complained with many warnings for this, but successfully linked
and can be ignored with option.

-Han Sangjin

···

2016-05-12 1:23 GMT+09:00 Saleem Abdulrasool via swift-dev < swift-dev@swift.org>:

On Tue, May 3, 2016 at 6:34 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Apr 26, 2016, at 08:43, Saleem Abdulrasool <compnerd@compnerd.org> >> wrote:

On Tue, Apr 12, 2016 at 9:32 AM, Saleem Abdulrasool < >> compnerd@compnerd.org> wrote:

On Monday, April 11, 2016, Joe Groff <jgroff@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 < >>>> compnerd@compnerd.org> wrote:
> On Wed, Apr 6, 2016 at 10:21 AM, Saleem Abdulrasool < >>>> compnerd@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
GitHub - compnerd/apple-swift at 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.

Just to chime in here (as asked by Saleem, um, a month ago) I think this
is the right way to go. We should handle the DLL-ish case (mark public
things ‘dllexport’ and references outside the Swift module ‘dllimport’),
and not worry about static linking (unnecessary dllimports).

(It seems __declspec(dllexport) is exactly the same as LLVM ‘public’ vs
‘hidden’—at least for Swift’s uses, even if that isn’t true generally.)

Yeah, for the most part, they serve similar purposes.

We can then come back later and design / add some kind of “I know this
object file is going to be statically linked into the executable” mode,
which will drop all the dllexports. We’d also want to encode this flag into
the serialized “swiftmodule” files (a library’s public interface), so that
we know not to use dllimport for anything we use from there.

Unfortunately, ATM, the runtime is compacted into the stdlib, which has
the small problem of making the stdlib have references to the runtime
functions as if it were being dynamically linked. We *could* just assume
that the any time that the LLVM module name is "Swift.*" we are building
the stdlib and not mark the runtime functions for external (import) dll
storage, but this seems rather fragile. The problem is that at IRGen time,
we no longer have access to the SILModule (AFAIK), so we don't have a way
to identify if we are the stdlib or not. Suggestions on how to handle that
would be appreciated.

Thanks for pushing on this!
Jordan

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

22

Experimenting with building for Windows-arm with MSVC, this approach
does work pretty well. But it seems hacky. Can we use
llvm::Module::addModuleFlag() to add a "SwiftStdlib" flag to the
module that the IRGenCode can check for?

Paul

···

On Wed, May 11, 2016 at 9:23 AM, Saleem Abdulrasool via swift-dev <swift-dev@swift.org> wrote:

Unfortunately, ATM, the runtime is compacted into the stdlib, which has the
small problem of making the stdlib have references to the runtime functions
as if it were being dynamically linked. We *could* just assume that the any
time that the LLVM module name is "Swift.*" we are building the stdlib and
not mark the runtime functions for external (import) dll storage, but this
seems rather fragile. The problem is that at IRGen time, we no longer have
access to the SILModule (AFAIK), so we don't have a way to identify if we
are the stdlib or not. Suggestions on how to handle that would be
appreciated.

23

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.

So what's the cleanest way to make this work in practice? I
experimented with the following hack, which worked for building the
stdlib and the SDK overlay but which is full of layer violations:

Sorry, I could've been more clear. For ordinary declarations, we know exactly
which module defines any symbols associated with them because we know
which module the declaration is in and ordinary declarations are always definitions.
A @_silgen_name declaration isn't itself a definition, but it's actually still
reasonable to assume that it's defined by the current module, which means
that as far as knowing where the symbol is defined goes, it really *is* a definition.
So there's no difference.

The right solution is for SILFunctions (well, at least the ones with public linkage)
to always carry a reference to their defining module. IRGen can then just key off
of that + its knowledge of the current module when emitting the llvm::GlobalValue
for the thing.

John.

···

On Oct 7, 2016, at 4:08 PM, Paul Menage <paul@paulmenage.org> wrote:
On Tue, Apr 26, 2016 at 8:49 AM, John McCall via swift-dev > <swift-dev@swift.org> wrote:

- Add a symbol tracking hook in SILGenNameAttr, such that when the
hook is active, whenever we encounter a _silgen_name() declaration we
record it in a set.

- Enable this symbol tracking just for the duration of parsing the
main module. Thus we end up with a set of all _silgen_name attributes
on functions declared in the current module, but not _silgen_name
attributes on functions imported from other modules.

- At various points in lib/IRGen/GenDecl.cc
(updateLinkageForDefinition, LinkInfo::createFunction,
LinkInfo::createVariable) check whether the symbol being used is in
the list of _silgen_name attributes from the current module, and if so
ignore the dll-import tag on the symbol when setting up the
llvm::GlobalValue.

It would be nicer to walk across the main module after parsing it to
find SILGenNameAttr instances, but I don't have a good idea how to
start with that. Then we could perhaps add the list of attributes to
the llvm::Module as some kind of llvm::Metadata object?

Paul

24

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@compnerd.org>:

On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev < > swift-dev@swift.org> wrote:

> On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev < >> swift-dev@swift.org> 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org

25

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 ?

-Han Sangjin

···

2016-05-08 8:01 GMT+09:00 Sangjin Han <tinysun.net@gmail.com>:

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@compnerd.org>:

On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev < >> swift-dev@swift.org> wrote:

> On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev < >>> swift-dev@swift.org> 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org

26

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.

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 (lhames@apple.com), to see what the right thing to do to reference DLL exports from JIT code is.

-Joe

···

On May 7, 2016, at 4:01 PM, Sangjin Han <tinysun.net@gmail.com> wrote:

  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@compnerd.org>:
On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev <swift-dev@swift.org> wrote:

> On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev <swift-dev@swift.org> 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org

27

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.

···

On Sat, May 7, 2016 at 7:55 PM, Sangjin Han <tinysun.net@gmail.com> wrote:

-Han Sangjin

2016-05-08 8:01 GMT+09:00 Sangjin Han <tinysun.net@gmail.com>:

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@compnerd.org>:

On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev < >>> swift-dev@swift.org> wrote:

> On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev < >>>> swift-dev@swift.org> 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org

28

Joe,

LLVM's MCJIT? Did you mean the REPL mode?

I'm not ready to ask a question or understand the answer about them. Maybe
it takes some time for me to handle them.
Currently, I want to concentrate on the immediate mode, dynamic/static
linking on Windows (MSVC).

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) )

I think we may consider for only MSVC, if the REPL in Cygwin works without
dllimport consideration.

-Han Sangjin

···

2016-05-10 2:06 GMT+09:00 Joe Groff <jgroff@apple.com>:

> On May 7, 2016, at 4:01 PM, Sangjin Han <tinysun.net@gmail.com> wrote:
>
> 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.

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 (
lhames@apple.com), to see what the right thing to do to reference DLL
exports from JIT code is.

-Joe

> 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@compnerd.org>:
> On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev < > swift-dev@swift.org> wrote:
>
> > On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev < > swift-dev@swift.org> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>

29

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?

-Joe

···

On May 9, 2016, at 7:19 PM, Saleem Abdulrasool <compnerd@compnerd.org> wrote:
On Sat, May 7, 2016 at 7:55 PM, Sangjin Han <tinysun.net@gmail.com> wrote:

-Han Sangjin

2016-05-08 8:01 GMT+09:00 Sangjin Han <tinysun.net@gmail.com>:
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@compnerd.org>:
On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev <swift-dev@swift.org> wrote:

> On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev <swift-dev@swift.org> 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org

30

Joe,

LLVM's MCJIT? Did you mean the REPL mode?

By immediate mode, do you mean "swift foo.swift", where the script is immediately compiled and executed? That also uses MCJIT.

I'm not ready to ask a question or understand the answer about them. Maybe it takes some time for me to handle them.
Currently, I want to concentrate on the immediate mode, dynamic/static linking on Windows (MSVC).

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.

-Joe

···

On May 10, 2016, at 3:11 PM, Sangjin Han <tinysun.net@gmail.com> wrote:

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) )

I think we may consider for only MSVC, if the REPL in Cygwin works without dllimport consideration.

-Han Sangjin

2016-05-10 2:06 GMT+09:00 Joe Groff <jgroff@apple.com>:

> On May 7, 2016, at 4:01 PM, Sangjin Han <tinysun.net@gmail.com> wrote:
>
> 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.

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 (lhames@apple.com), to see what the right thing to do to reference DLL exports from JIT code is.

-Joe

> 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@compnerd.org>:
> On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev <swift-dev@swift.org> wrote:
>
> > On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev <swift-dev@swift.org> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>

31

Yes, I ran 'swift Hello.swift'. I didn't know there is MCJIT in that.
I'll ask and find the answer for it.

-Han Sangjin

···

2016-05-11 7:14 GMT+09:00 Joe Groff <jgroff@apple.com>:

> On May 10, 2016, at 3:11 PM, Sangjin Han <tinysun.net@gmail.com> wrote:
>
> Joe,
>
> LLVM's MCJIT? Did you mean the REPL mode?

By immediate mode, do you mean "swift foo.swift", where the script is
immediately compiled and executed? That also uses MCJIT.

>
> I'm not ready to ask a question or understand the answer about them.
Maybe it takes some time for me to handle them.
> Currently, I want to concentrate on the immediate mode, dynamic/static
linking on Windows (MSVC).

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.

-Joe

>
> 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) )
>
> I think we may consider for only MSVC, if the REPL in Cygwin works
without dllimport consideration.
>
> -Han Sangjin
>
> 2016-05-10 2:06 GMT+09:00 Joe Groff <jgroff@apple.com>:
>
> > On May 7, 2016, at 4:01 PM, Sangjin Han <tinysun.net@gmail.com> wrote:
> >
> > 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.
>
> 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 (
lhames@apple.com), to see what the right thing to do to reference DLL
exports from JIT code is.
>
> -Joe
>
> > 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@compnerd.org>:
> > On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev < > swift-dev@swift.org> wrote:
> >
> > > On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev < > swift-dev@swift.org> 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@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
> >
> >
> >
> > --
> > Saleem Abdulrasool
> > compnerd (at) compnerd (dot) org
> >
>
>

32

>
> 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.

···

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

> On May 9, 2016, at 7:19 PM, Saleem Abdulrasool <compnerd@compnerd.org > <javascript:;>> wrote:
> On Sat, May 7, 2016 at 7:55 PM, Sangjin Han <tinysun.net@gmail.com > <javascript:;>> wrote:

-Joe

>
>
> -Han Sangjin
>
>
>
>
> 2016-05-08 8:01 GMT+09:00 Sangjin Han <tinysun.net@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@compnerd.org
<javascript:;>>:
> On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev < > swift-dev@swift.org <javascript:;>> wrote:
>
> > On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev < > swift-dev@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@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

33

It might help to centralize the logic. In IRGen, there's a function getIRLinkage that decomposes a semantic SIL visibility into an LLVM linkage and visibility pair:

It could be modified to produce a three-element tuple that includes the DLL storage class too.

-Joe

···

On May 10, 2016, at 2:25 PM, Saleem Abdulrasool <compnerd@compnerd.org> wrote:

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

> On May 9, 2016, at 7:19 PM, Saleem Abdulrasool <compnerd@compnerd.org> wrote:
>
> On Sat, May 7, 2016 at 7:55 PM, Sangjin Han <tinysun.net@gmail.com> 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.

34

Hah. You should have a look at the pull request :-). Thats exactly what I
had done. However, that function is not used globally and I just audited
the other calls for llvm::Function::Create and llvm::GlobalAlias::create.
I believe that it should be correct now. Thanks for the original hint that
I had missed an instance of the GlobalAlias. I also updated the test cases
that I had for this. Additional input on what would be good test cases
would be good too.

···

On Tue, May 10, 2016 at 2:29 PM, Joe Groff <jgroff@apple.com> wrote:

It might help to centralize the logic. In IRGen, there's a function
getIRLinkage that decomposes a semantic SIL visibility into an LLVM linkage
and visibility pair:

https://github.com/apple/swift/blob/master/lib/IRGen/GenDecl.cpp#L1201

It could be modified to produce a three-element tuple that includes the
DLL storage class too.

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org