Previously, AsyncFunctionPointer constants were signed as code. That
was incorrect considering that these constants are in fact data. Here,
that is fixed.
rdar://76118522
Certain targets don't support the async calling convention, so we first
add the feature check to avoid breaking the codegen/runtime while doing
gradual rollout for different targets.
* Adds support for generating code that uses swiftasync parameter lowering.
* Currently only arm64's llvm lowering supports the swift_async_context_addr intrinsic.
* Add arm64e pointer signing of updated swift_async_context_addr.
This commit needs the PR llvm-project#2291.
* [runtime] unittests should use just-built compiler if the runtime did
This will start to matter with the introduction of usage of swiftasync parameters which only very recent compilers support.
rdar://71499498
Previously Swift enabled the "UseOdrIndicator" ASan instrumentation mode
and gave no option to disable this. This probably wasn't intentional but
happened due to the fact the
`createModuleAddressSanitizerLegacyPassPass()` function has a default
value for the `UseOdrIndicator` parameter of `true` and in Swift we
never specified this parameter explicitly.
Clang disables the "UseOdrIndicator" mode by default but allows it to be
enabled using the `-fsanitize-address-use-odr-indicator` flag.
Having "UseOdrIndicator" off by default is probably the right
default choice because it bloats the binary. So this patch changes the
Swift compiler to match Clang's behavior.
This patch disables the "UseOdrIndicator" mode by default but adds a
hidden driver and frontend flag (`-sanitize-address-use-odr-indicator`)
to enable it. The flag is hidden so that we can remove it in the future
if needed.
A side effect of disabling "UseOdrIndicator" is that by we will no
longer use private aliases for poisoning globals. Private aliases were
introduced to avoid crashes
(https://github.com/google/sanitizers/issues/398) due to ODR violations
with non-instrumented binaries. On Apple platforms the use of two-level
namespaces probably means that using private aliases wasn't ever really
necessary to avoid crashes. On platforms with a flat linking namespace
(e.g. Linux) using private aliases might matter more but should users
actually run into problems they can either:
* Fix their environment to remove the ODR, thus avoiding the crash.
* Instrument the previously non-instrumented code to avoid the crash.
* Use the new `-sanitize-address-use-odr-indicator` flag
rdar://problem/69335186
Add a debugging mechanism that enables the JIT to dump the LLVM IR and
object files to enable debugging the JIT. This makes it easier to debug
the JIT mode failures. The idea was from Lang Hames!
Two protocol conformance descriptors are passed to
swift_compareProtocolConformanceDecriptors from generic metadata
accessors when there is a canonical prespecialization and one of the
generic arguments has a protocol requirement.
Previously, the descriptors were incorrectly being passed without
ptrauth processing: one from the witness table in the arguments that are
passed in to the accessor and one known statically.
Here, the descriptor in the witness table is authed using the
ProtocolConformanceDescriptor schema. Then, both descriptors are signed
using the ProtocolConformanceDescriptorsAsArguments schema. Finally, in
the runtime function, the descriptors are authed.
This commit adds -lto flag for frontend to enable LTO at LLVM level.
When -lto=llvm given, compiler emits LLVM bitcode file instead of object
file and adds index summary for LTO.
In addition for ELF format, emit llvm.dependent-libraries section to
embed auto linking information
Previously the path to covered files in the __LLVM_COV / __llvm_covmap
section were absolute. This made remote builds with coverage information
difficult because all machines would have to have the same build root.
This change uses the values for `-coverage-prefix-map` to remap files in
the coverage info to relative paths. These paths work correctly with
llvm-cov when it is run from the same source directory as the
compilation, or from a different directory using the `-path-equivalence`
argument.
This is analogous to this change in clang https://reviews.llvm.org/D81122
This commit adds -lto flag for driver to enable LTO at LLVM level.
When -lto=llvm given, compiler emits LLVM bitcode file instead of object
file and perform thin LTO using libLTO.dylib plugin.
When -lto=llvm-full given, perform full LTO instead of thin LTO.
Clang provides options to override that default value.
These options are accessible via the -Xcc flag.
Some Swift functions explicitly disable the frame pointer.
The clang options will not override those.
The Objective-C runtime expects a signed pointer here. The existing test
would have caught this, except it was always disabled because the
symbol name passed to the dlsym() check should not have had the leading
'_'.
Fixes <rdar://problem/57679510>.
Regardless of any flags, the stdlib will have its generic metadata
prespecialized.
Temporarily reintroduced the flag to enable the feature flag while
preserving the flag to disable it and changed the default back to off
for the moment.
Previously, -Xfrontend -prespecialize-generic-metadata had to be passed
in order for generic metadata to be prespecialized. Now it is
prespecialized unless -Xfrontend
-disable-generic-metadata-prespecialization is passed.
This was being done at an odd point in the frontend presumably because by that point the private discriminator had been fully computed. Instead, push the conditions for generating the prefix data down to debug info generation and stop mutating IRGenOptions::DebugFlag in the frontend.
The new frontend flag -prespecialize-generic-metadata must be passed in
order for generic metadata to be specialized statically.
rdar://problem/56984885
The new option `-sanitize-recover=` takes a list of sanitizers that
recovery instrumentation should be enabled for. Currently we only
support it for Address Sanitizer.
If the option is not specified then the generated instrumentation does
not allow error recovery.
This option mirrors the `-fsanitize-recover=` option of Clang.
We don't enable recoverable instrumentation by default because it may
lead to code size blow up (control flow has to be resumable).
The motivation behind this change is that today, setting
`ASAN_OPTIONS=halt_on_error=0` at runtime doesn't always work. If you
compile without the `-sanitize-recover=address` option (equivalent to
the current behavior of the swift compiler) then the generated
instrumentation doesn't allow for error recovery. What this means is
that if you set `ASAN_OPTIONS=halt_on_error=0` at runtime and if an ASan
issue is caught via instrumentation then the process will always halt
regardless of how `halt_on_error` is set. However, if ASan catches an
issue via one of its interceptors (e.g. memcpy) then `the halt_on_error`
runtime option is respected.
With `-sanitize-recover=address` the generated instrumentation allows
for error recovery which means that the `halt_on_error` runtime option
is also respected when the ASan issue is caught by instrumentation.
ASan's default for `halt_on_error` is true which means this issue only
effects people who choose to not use the default behavior.
rdar://problem/56346688
This option is useful to debug the compiler itself, to simulate debug info as it
would be generated when producing optimized code, but without the unpredictable
output of an optimizing debugger.
Mixes the state of all sanitizers, not just the fuzzer, into the module hash used to decide whether to skip LLVM codegen. I don’t actually know of a case where one of the other sanitizers will generate identical IR and different machine code, but being defensive costs us very little.
Replaces getLLVMCodeGenOptionsHash(), which combined a bunch of individual bits into a string, with writeLLVMCodeGenOptionsTo(), which writes each one separately into a raw_ostream.
This is intended to be make the hashing more future-proof. The current design needs to know exactly how many bits each of the values needs; if any of the values grew and you forgot to update this function, its bits would interfere with those of an earlier value in the hash. This new design is expected to be slightly slower, but more robust to future change in the compiler.
When rebuilding a .o file, we hash the IR generated by IRGen and compare it to a hash embedded in the .o file. If they match, we simply skip asking LLVM to optimize and generate code. Certain flags that control our LLVM configuration are mixed into the hash, but the -profile-generate flag was not one of them. This usually wouldn’t matter because profiling would insert additional code into the IR, but in edge cases like empty files or files containing only protocol declarations, it could cause linker errors when profiling was turned off.
This change adds the `GenerateProfile` flag into the IR hash, ensuring that we always recompile, even if the IR was identical.
Fixes rdar://problem/54126622.
We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.
rdar://problem/50057445
module imports. This is useful when building redistributable static
archives, since any pointers into the CLang module cache won't be
portable.
When using this option the Clang type fallback path in LLDB will be
less useful since DWARF type information from those modules will not
be available unless another object file compiled without the option
imported the same modules.
rdar://problem/48827784
In LLDB expressions, references to private metadata accessors may be
emitted and need to be bound to symbols available in the attached
program, even if these symbols are only supposed to have private
visibility within the program.
Also rdar://problem/48018240
Windows does not permit cross-module data accesses to be direct. This
is a problem for public protocols with root conformances which are
external. Use a runtime initialiser for the root protocol conformance
chaining to alleviate this issue. This shows up in the Foundation
build.
The layouts of resilient value types shipped in the Swift 5 standard library
x and overlays will forever be frozen in time for backward deployment to old
Objective-C runtimes. This PR ensures that even if the layouts of these types
evolve in the future, binaries built to run on the old runtime will continue
to lay out class instances in a manner compatible with Swift 5.
Fixes <rdar://problem/45646886>.
