The frontend supports this via new options -index-unit-output-path and
-index-unit-output-path-filelist that mirror -o and -output-filelist. These are
intended to allow sharing index data across builds in separate directories (so
different -o values) that are otherwise equivalent as far as the index data is
concerned (e.g. an ASAN build and a non-ASAN build) by supplying the same
-index-unit-output-path for both.
This change updates the driver to add these new options to the frontend
invocation 1) when a new "index-unit-output-path" entry is specified for one
or more input files in the -output-file-map json or 2) if -index-file is
specified, when a new -index-unit-output-path driver option is passed.
Resolves rdar://problem/74816412
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
The only available method to check for features at the moment is through
version checks. This is errorprone and doesn't work well for OSS
toolchains or locally built compilers.
features.json is intended to communicate to build systems that a new
flag is available, in order to assist with a transitional period where
not all supported toolchains may have a particular flag. It is *not*
intended to be a comprehensive report of all flags available.
Note that the names are intended to be features, so while they may match
up to the corresponding flag name, this isn't necessarily the case.
LLVM ships a hardened memory allocator called Scudo:
https://llvm.org/docs/ScudoHardenedAllocator.html. This allocator
provides additional mitigations against heap-based vulnerabilities, but
retains sufficient performance to be safely run in production
applications.
While ideal Swift applications are obviously written in pure Swift, in
practice most applications contain some amount of code written in
less-safe languages. Additionally, plenty of Swift programs themselves
contain unsafe code, particularly when attempting to implement
high-performance data structures. These sources of unsafety introduce
the risk of memory issues, and having the option to use the Scudo
allocator is a useful defense-in-depth tool.
This patch enables `-sanitize=scudo` as an extra `swiftc` flag. This
sanitizer is only supported on Linux, so no further work is required to
enable it on Windows or Apple platforms. As this "sanitizer" is only a
runtime component, we do not require any wider changes to instrument
code. This is similar to clang's `-fsanitize=scudo` flag.
The Swift driver rejects platforms that don't support Scudo using an
existing mechanism in the Driver that is not part of this patch. This
mechanism is in swift::parseSanitizerArgValues(...)
(lib/Option/SanitizerOptions.cpp). The mechanism determines if a
sanitizer is supported by checking for the existence of the
corresponding sanitizer runtime library in the compiler's resource
directory. The Scudo runtime library currently only exists in the
Linux compiler resource directory. This results in the driver only
allowing Scudo when targeting Linux.
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 is a follow up to the discussion on #22740 to switch the host
libraries to use the `target_link_libraries` rather than the
`LINK_LIBRARIES` special handling. This allows the dependency to be
properly tracked by CMake and allows us to use the more modern syntax.
This change allows the swift driver to link the ubsan runtime if
`-sanitize=undefined` is specified.
This is useful for sanitizing linked Objective-C code.
This reverts commit 121f5b64be.
Sorry to revert this again. This commit makes some pretty big changes. After
messing with the merge-conflict created by this internally, I did not feel
comfortable landing this now. I talked with Saleem and he agreed with me that
this was the right thing to do.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
Similarly to Clang, the flag enables coverage instrumentation, and links
`libLLVMFuzzer.a` to the produced binary.
Additionally, this change affects the driver logic, and enables the
concurrent usage of multiple sanitizers.
With this patch different sanitizers (tsan/asan) will be enabled or
disabled on the driver level on a particular OS depending on whether
the required library is present.
The current patch only supports Darwin architectures, but Linux support
should not be hard to add.
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.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
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.
"Sanitizer Coverage" with a new flag ``-sanitize-coverage=``. This
flag is analogous to Clang's ``-fsanitize-coverage=``.
This instrumentation currently requires ASan or TSan to be enabled
because the module pass created by ``createSanitizerCoverageModulePass()``
inserts calls into functions found in compiler-rt's "sanitizer_common".
"sanitizer_common" is not shipped as an individual library but instead
exists in several of the sanitizer runtime libraries so we have to
link with one of them to avoid linking errors.
The rationale between adding this feature is to allow experimentation
with libFuzzer which currently relies on "Sanitizer Coverage"
instrumentation.
The options themselves are now in swift::options (from swift::driver::options).
The soon-to-be-renamed createDriverOptTable() is now directly in the swift namespace.
Swift SVN r19825
This allows swiftFrontend to drop its dependency on swiftDriver, and could
someday allow us to move the integrated frontend's option parsing out of
swiftFrontend (which would allow other tools which use swiftFrontend to
exclude the option table entirely).
Swift SVN r19824
