Restructure the COFF metadata handling to use the linker section
grouping to emit section start/stop markers in the appropriate location.
This allows us to lookup the sections statically without having to the
walk the entire image structure.
Introduce a constructor for PE/COFF binaries. This will ensure that the
registration occurs for all modules appropriately. This should resolve
rdar://problem/19045112. The registration should occur prior to
`DllMain` being invoked from `DllMainCRTStartup`.
Restructure the ELF handling to be completely agnostic to the OS.
Rather than usng the loader to query the section information, use the
linker to construct linker tables and synthetic markers for the
beginning and of the table. Save off the values of these pointers and
pass them along through the constructor to the runtime for registration.
This removes the need for the begin/end objects. Remove the special
construction of the begin/end objects through the special assembly
constructs, preferring to do this in C with a bit of inline assembly to
ensure that the section is always allocated.
Remove the special handling for the various targets, the empty object
file can be linked on all the targets.
The new object file has no requirements on the ordering. It needs to
simply be injected into the link.
Name the replacement file `swiftrt.o` mirroring `crt.o` from libc. Merge
the constructor and the definition into a single object file.
This approach is generally more portable, overall simpler to implement,
and more robust.
Thanks to Orlando Bassotto for help analyzing some of the odd behaviours
when switching over.
This adds the swift include path manually to the builds for the stubs
and the runtime. This has no impact for the build currently. However,
adding the additional include directory will enable a standalone build
for the stdlib.
* Revert "[strip -ST] Disable runtime stack trace dumping on Darwin when asserts are disabled."
This reverts commit 6bc28ff1c9.
* Bring back important fixes from the revert of 6bc28ff1c9.
* Change swift::swift_reportError to only print the backtrace in assert builds (swift::warning prints backtrace always).
This commit disables runtime stack trace dumping via dladdr on Darwin when
asserts are disabled.
This stack trace dumping was added as a way to improve the ability to debug the
compiler for compiler developers. This is all well and good but having such a
feature always enabled prevents us from reducing the size of the swift standard
library by eliminating the swift nlist.
rdar://31372220
When cross-compiling for android ARM, it is possible that the system
linker does not support the target. However, in order to cross-compile
the target runtime, we need to adjust the linker to the target linker.
If one is not specified, fall back to the current behaviour of using the
system linker.
These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
This breaks the build on exherbo, which uses target tripled linker
names. Furthermore, the default name on unix-ish systems for the linker
is `ld`. This can be a symlink to a specific implementation, usually
named as ld.<name> (e.g. `ld.bfd` or `ld.gold`). Use the cmake variable
for the linker rather than hardcoding the name.
- Create separate swift_begin.o/swift_end.o for lib/swift and
lib/swift_static. The static swift_begin.o does not call
swift_addNewDSOImage() at startup.
- Update ToolChains.cpp to use the correct swift_begin.o/swift_end.o
files for the `-static-stdlib` and `-static-executable` options.
- Rename swift::addNewDSOImage() to swift_addNewDSOImage() and
export using SWIFT_RUNTIME_EXPORT.
- Move ELF specific parts of ImageInspection.h into
ImageInspectionELF.h.
- For ELF targets, keep track of shared objects as they are
dynamically loaded so that section data can be added to
the protocol conformance and type metadata caches after
initialisation (rdar://problem/19045112).
The runtime and stubs are built for ALL targets, not specific ones. This allows
us to configure when cross-compiling to Windows again. Collapse the dual
addition of the swiftRuntime into a single build. This unifies the runtime
build for the apple and non-Apple SDKs. The difference here was the ObjC
interop sources. In order to deal with that unification add a CPP macro to
indicate whether the interop sources should be included or not.
- Add ImageInspectionStatic.cpp to lookup protocol conformance
and metadata sections in static binaries
- For Linux, build libswiftImageInspectionShared.a and
libswiftImageInspectionStatic.a for linking with libswiftCore.a.
This allows static binaries to be built without linking to
libdl. libswiftImageInspectionShared (ImageInspectionELF.cpp) is
automatically compiled into libswiftCore.so
- Adds -static-executable option to swiftc to use along with
-emit-executable that uses linker arguments in
static-executable-args.lnk. This also requires a libicu
to be compiled using the --libicu which has configure options
that dont require libdl for accessing ICU datafiles
- Static binaries only work on Linux at this time
The code we use to interface with the platform dynamic linker is turning into a rat's nest of conditionals that's hard to maintain and extend. Since ELF, Mach-O, and PE platforms have pretty fundamentally different dynamic linker interfaces and capabilities, it makes sense to factor that code into a separate file per-platform, instead of trying to conditionalize the logic in-line. This patch factors out a much simpler portable interface for lazily kicking off the protocol conformance and type metadata lookup caches, and factors the guts out into separate MachO, ELF, and Win32 backends. This should also be a much cleaner interface to interface static binary behavior into, assisting #5349.
The `add_swift_library` CMake function takes an optional `TARGET_SDKS`
parameter. When used, only CMake targets for the specified SDKs are added.
Refactor `stdlib/public/runtime` to use this parameter. This also eliminates
logic that determines additional flags or source files to include based on
`SWIFT_HOST_VARIANT`, which makes it easier for hosts to add targets for
different platforms.
Rather than having Sema provide a default implementation of
Error._code when needed, introduce a runtime function to extract the
default code, so that we can provide a default implementation via a
protocol extension in the standard library.
If the Swift error wrapped in a _SwiftNativeNSError box conforms to
Hashable, the box now uses the Swift's conformance to Hashable.
Part of rdar://problem/27574348.
If there's no better mapping for a Swift value into an Objective-C object for bridging purposes, we can fall back to boxing the value in a class. This class doesn't have any public interface beyond being `NSObject`-conforming in Objective-C, but is recognized by the Swift runtime so that it can be dynamically cast back to the boxed type.
When the standard library is built dynamically on COFF targets, the public
interfaces must be decorated in order to generate a proper DLL which can be
confused by the dependent libraries. When the exported interface is used, it
must be indirectly addressed. This can be done manually in code or the MS
extension of `__declspec(dllimport)` may be used to indicate to the compiler
that this symbol be addressed indirectly. This permits building more pieces of
the standard library dynamically on Windows.
Always include all the sources as we cannot include object libraries to be
subsumed. This allows us to conditionally build the swift runtime for foreign
hosts simultaneously (e.g. cross compile for Linux and Windows simultaneously).
Build the section_magic libraries for all the ELFish SDKs that have been
configured. This allows us to build for SDKs which dont match the object format
at the same time (e.g. Linux and Windows).
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
This patch is for libswiftCore.lib, linking with the library set of Visual Studio 2015. Clang with the option -fms-extension is used to build this port.
This is the approved subpatch of a large patch.
Declarations with protected visibility are assumed to be defined
within the current linkage unit, so we have to use default visibility
if we don't know that we're building that. Teach the shim
visibility header to only use protected visibility when the
__SWIFT_CURRENT_DYLIB macro is defined, and define it when building
the standard library. Eventually we should change
SWIFT_RUNTIME_STDLIB_INTERFACE and SWIFT_RUNTIME_EXPORT to be
parameterized by the defining dylib so that this works for all the
overlay stubs, too; for now, special-casing swiftCore is necessary
to fix the LInux build.
