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.
Allow users to pass `.swiftmodule` files into the Swift driver when
compiling without `-g`. The `.swiftmodule` files are then passed to the
linker via `-add_ast_path` so that LLDB can access their AST
information.
This addresses one of two driver changes suggested in the comments of
https://bugs.swift.org/browse/SR-2660.
When the Swift driver is invoked with the `-emit-library` option, but
without an `-o` option that specifies the emitted library's filename,
logic in the `getOutputFilename()` function derives a filename:
`"lib" + <a plasible base name>"`, and then the value of the
`LTDL_SHLIB_EXT` macro.
There are two problems here:
1. Windows shared library file names, by convention, do not begin with "lib".
2. The `LTDL_SHLIB_EXT` macro is set by
`llvm/cmake/modules/HandleLLVMOptions.cmake`, based on
`CMAKE_SHARED_LIBRARY_SUFFIX`, a built-in CMake variable that is set
at the time LLVM is configured to be built. So, if LLVM and Swift
were built on a Linux machine, but the `swiftc` executable that was
built was then invoked to produce a shared library for a Darwin target,
the library would have a ".so" suffix, not ".dylib". (It's for this
reason that the tests for this name inference, in
`test/Driver/linker.swift`, must use a regular expression that
matches both ".dylib" and ".so", despite specifying a Darwin
`-target`.)
In order to produce conventionally correct prefixes and suffixes based
on the target, modify the `getOutputFilename()` function to take an
`llvm::Triple` argument.
This test validates the arguments passed to the linker when statically
linking the swift standard library. Currently in order to ensure that no
-rpath is passed, we're using FileCheck's -implicit-check-not flag, and
strictly validating the order of the arguments. The order doesn't really
matter here but is required for that flag to validate that no -rpath is
passed.
(macOS? OS X? How does this work for past OSs?)
Noticed by inspection. Xcode doesn't use swiftc to link, and the few
things that went into arclite between iOS 7 and iOS 8 weren't critical,
but we should still get this right.
This adds an Android target for the stdlib. It is also the first
example of cross-compiling outside of Darwin.
Mailing list discussions:
1. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151207/000171.html
2. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000492.html
The Android variant of Swift may be built using the following `build-script`
invocation:
```
$ utils/build-script \
-R \ # Build in ReleaseAssert mode.
--android \ # Build for Android.
--android-ndk ~/android-ndk-r10e \ # Path to an Android NDK.
--android-ndk-version 21 \
--android-icu-uc ~/libicu-android/armeabi-v7a/libicuuc.so \
--android-icu-uc-include ~/libicu-android/armeabi-v7a/icu/source/common \
--android-icu-i18n ~/libicu-android/armeabi-v7a/libicui18n.so \
--android-icu-i18n-include ~/libicu-android/armeabi-v7a/icu/source/i18n/
```
Android builds have the following dependencies, as can be seen in
the build script invocation:
1. An Android NDK of version 21 or greater, available to download
here: http://developer.android.com/ndk/downloads/index.html.
2. A libicu compatible with android-armv7.
Start sketching out a way for individual jobs to request filelists for
their inputs or their outputs. This should cover all the cases mentioned
in ad945426.
More https://bugs.swift.org/browse/SR-280.
Previously jobs had to grovel this information out of the raw argument
list, which dropped the types we had inferred on input files. This
makes things more consistent across the compiler, though arguably we
should be able to designate "primary" and "non-primary" inputs on a
per-action basis rather than resorting to "global" state.
Use this new information to stop passing object file inputs to the
Swift frontend, fixing rdar://problem/23213785.
The list wouldn't have to live on the Compilation, but I'm going to use
it to fix SR-280 / rdar://problem/23878192 as well.
This reverts commit 58cfa27eb5.
We require at least clang-3.6 for C++14 build support but
Ubuntu 14.04's clang-3.6 package does not lay down the symlink
/usr/bin/clang++ -> /usr/bin/clang++-3.6. We will require a
clang++ alternatives entry or symlink when building for these
systems (see README.md).
In most Linux distributions, installing a clang package other than the
default unversioned one will not install a symlink from /usr/bin/clang++
-> /usr/bin/clang++-N-M, which can break builds with a not so great
diagnostic (a separate problem).
"ld" and "clang++" are hard-coded in the link job actions, so provide a
frontend flag, -linker-path, as a customization point for these.
rdar://problem/23537079
Deploying to older OSs requires linking in a compatibility library called
"arclite", but this library isn't open source and won't be distributed with
our open source downloads. Fall back to the version in Xcode.
The next step is to remove the local symlink used in builds, but I wanted to
handle that separately.
rdar://problem/23421436
The "Tool" abstraction wasn't buying us enough to deserve the added
complexity. Now a ToolChain turns Actions into Jobs, and every helper
tool is searched for relative to Swift first. Much simpler.
Swift SVN r31563
- Add frontend and standard library build support for tvOS.
- Add frontend support for watchOS.
watchOS standard library builds are still disabled during SDK bring-up.
To build for TVOS, specify --tvos to build-script.
To build for watchOS, specify --watchos to build-script (not yet supported).
This patch does not include turning on full tests for TVOS or watchOS, and
will be included in a follow-up patch.
Swift SVN r26278
This works by loading the protocols from a specially named symbol,
which is generated by the linker through the help of a linker script
that merges all of the protocol conformance blocks into one section
with its size at the start of it and points a global symbol at
the section.
We do all this because unlike MachO, section information does not
survive to be loaded into memory with ELF binaries. Instead,
the mappings that survive are 'segments', which contain one or
more sections. Information about how these relate to their original
sections is difficult, if not impossible, to obtain at runtime.
Swift SVN r23518
This works by loading the protocols from a specially named symbol,
which is generated by the linker through the help of a linker script
that merges all of the protocol conformance blocks into one section
with its size at the start of it and points a global symbol at
the section.
We do all this because unlike MachO, section information does not
survive to be loaded into memory with ELF binaries. Instead,
the mappings that survive are 'segments', which contain one or
more sections. Information about how these relate to their original
sections is difficult, if not impossible, to obtain at runtime.
Swift SVN r23475
(when in -emit-library mode)
The one catch is that if you specify an output file named "libFOO" with no
extension, the module name will still be "libFOO", not "FOO". Explicitly
providing both -o and -module-name is always allowed.
<rdar://problem/17827584>
Swift SVN r20869
Without this, clients that don't use a CompilerInstance (like LLDB) won't
have target configuration options available.
Also, move minimum OS checking into the driver. This makes sure the check
happens early (and only once), and in general fits the philosophy of
allowing the frontend to use configurations that might be banned for users.
<rdar://problem/17688913>
Swift SVN r20701
This matches Clang's behavior, though this implementation does not check
that it's actually on a platform that uses dsymutil.
<rdar://problem/16012971>
Swift SVN r20529
