Weak import semantics are not available on PE/COFF. Ensure that we do not mark
the type as having weak import semantics. Otherwise, the dllimport'ed symbol is
marked as `dso_local` which is invalid.
Also have swift-reflection-test check if the symbol exists. This allows swift-reflection-test to work with older Remote Mirror dylibs that don't have it.
rdar://problem/50030805
This symbol is meant to be exposed to users of the SwiftRemoteMirror
library which requires that it is explicitly marked with the appropriate
DLL storage on Windows. This should repair the Windows build.
Recent Swift uses 2 as the is-Swift bit when running on newer versions, and 1 on older versions. Since it's difficult or impossible to know what we'll be running on at build time, make the selection at runtime.
* Change the RemoteMirror API to have extensible data layout callback
* Use DLQ_Get prefix on DataLayoutQueryType enum values
* Simplify MemoryReaderImpl and synthesize minimalDataLayoutQueryFunction
Mark the public interfaces with the appropriate visibility/dll storage.
This fixes an issue with the Windows build which keeps the
SwiftRemoteMirror.dll out of date constantly as no import library is
created. That occurs due to the fact that the library does not export
any interfaces.
Take the opportunity to move the public interfaces to protected
visibility on ELF.
* Remove getPointerSize and getSizeSize functions, replace with a single PointerSize value.
* Remove imageLength parameter from addImage, calculate it internally instead.
* Check remote mirrors libraries' metadata version and reject them if it's too old.
* Shim GetStringLength and GetSymbolAddress for the legacy library since we don't pass the caller's context pointer through directly.
* Actually set the IsLegacy flag in the Library struct.
* Implement ownsObject by tracking each added image's data segment and checking metadata pointers against them. The previous approach didn't work.
They would think the type 'addr_t' is defined in the standard library
because it has the same name format with the types in <cstdint>. In
addition, the definition conflicts in Cygwin which defines it differently
in the system library.
Implement the ReflectionContext's implementation of:
swift_reflection_projectExistential.
First, we get the type info of the existential typeref - it should be a
record type info. If it's a class existential, it has trivial layout:
the first word is a pointer to the class instance. Otherwise, if the
value fits in the 3-word buffer of the existential container, it
trivially is also at the start of the container. Otherwise, the value is
off in a heap box somewhere, but the first word of the container is a
pointer to that box.
Closure context layout will depend on the instance itself as well
as the isa pointer, because instead of instantiating metadata for
closures that capture generic parameters, we store the substitutions
inside the context itself.
For classes, this entry point just reads the isa pointer, applies
the isa mask and proceeds down the metadata path.
For now, the only the latter is hooked up.
Also, use the instance layout entry point in swift-reflection-test,
so that we can dump the layout of a class instance and not the
lowering of the reference value.
This tool should test the usage from SwiftRemoteMirror dylib and
the C API, since that is the public interface from which we're
vending the remote reflection functionality.
This API will take a pointer to the start of an existential
container and its typeref and provide a typeref for its
instance type and the address to the start of the instance's
data.
This has a dummy implementation that returns false for now.
swift_reflection_createReflectionContext was defaulting to C++ mangling
because the declaration under extern C in the header didn't match
its signature.
In order to perform layout, the remote mirrors library needs to know
about the size, alignment and extra inhabitants of builtin types.
Ideally we would emit a reflection info section in libswiftRuntime.o,
but in the meantime just duplicate builtin type metadata for all
builtin types referenced from the current module instead.
In practice only the stdlib and a handful of overlays like the SIMD
overlay use builtin types, and only a few at a time.
Tested manually by running swift-reflection-tool on the standard
library -- I'll add automated tests by using -parse-stdlib to
reference Builtin types in a subsequent patch that adds more layout
logic.
NFC if -enable-reflection-metadata is off.
