This patch introduces the runtime components for type sanitizer: a
sanitizer for type-based aliasing violations.
It is based on Hal Finkel's https://reviews.llvm.org/D32197.
C/C++ have type-based aliasing rules, and LLVM's optimizer can exploit
these given TBAA metadata added by Clang. Roughly, a pointer of given
type cannot be used to access an object of a different type (with, of
course, certain exceptions). Unfortunately, there's a lot of code in the
wild that violates these rules (e.g. for type punning), and such code
often must be built with -fno-strict-aliasing. Performance is often
sacrificed as a result. Part of the problem is the difficulty of finding
TBAA violations. Hopefully, this sanitizer will help.
For each TBAA type-access descriptor, encoded in LLVM's IR using
metadata, the corresponding instrumentation pass generates descriptor
tables. Thus, for each type (and access descriptor), we have a unique
pointer representation. Excepting anonymous-namespace types, these
tables are comdat, so the pointer values should be unique across the
program. The descriptors refer to other descriptors to form a type
aliasing tree (just like LLVM's TBAA metadata does). The instrumentation
handles the "fast path" (where the types match exactly and no
partial-overlaps are detected), and defers to the runtime to handle all
of the more-complicated cases. The runtime, of course, is also
responsible for reporting errors when those are detected.
The runtime uses essentially the same shadow memory region as tsan, and
we use 8 bytes of shadow memory, the size of the pointer to the type
descriptor, for every byte of accessed data in the program. The value 0
is used to represent an unknown type. The value -1 is used to represent
an interior byte (a byte that is part of a type, but not the first
byte). The instrumentation first checks for an exact match between the
type of the current access and the type for that address recorded in the
shadow memory. If it matches, it then checks the shadow for the
remainder of the bytes in the type to make sure that they're all -1. If
not, we call the runtime. If the exact match fails, we next check if the
value is 0 (i.e. unknown). If it is, then we check the shadow for the
remainder of the byes in the type (to make sure they're all 0). If
they're not, we call the runtime. We then set the shadow for the access
address and set the shadow for the remaining bytes in the type to -1
(i.e. marking them as interior bytes). If the type indicated by the
shadow memory for the access address is neither an exact match nor 0, we
call the runtime.
The instrumentation pass inserts calls to the memset intrinsic to set
the memory updated by memset, memcpy, and memmove, as well as
allocas/byval (and for lifetime.start/end) to reset the shadow memory to
reflect that the type is now unknown. The runtime intercepts memset,
memcpy, etc. to perform the same function for the library calls.
The runtime essentially repeats these checks, but uses the full TBAA
algorithm, just as the compiler does, to determine when two types are
permitted to alias. In a situation where access overlap has occurred and
aliasing is not permitted, an error is generated.
As a note, this implementation does not use the compressed shadow-memory
scheme discussed previously
(http://lists.llvm.org/pipermail/llvm-dev/2017-April/111766.html). That
scheme would not handle the struct-path (i.e. structure offset)
information that our TBAA represents. I expect we'll want to further
work on compressing the shadow-memory representation, but I think it
makes sense to do that as follow-up work.
This includes build fixes for Linux from Mingjie Xu.
Depends on #76260 (Clang support), #76259 (LLVM support)
PR: https://github.com/llvm/llvm-project/pull/76261
This fixes remaining issues in my previous PR #90959.
Changes:
- Removed dependency on LLVM header in `xray_interface.cpp`
- Fixed XRay patching for some targets due to missing changes in
architecture-specific patching functions
- Addressed some remaining compiler warnings that I missed in the
previous patch
- Formatting
I have tested these changes on `x86_64` (natively), as well as
`ppc64le`, `aarch64` and `arm32` (cross-compiled and emulated using
qemu).
**Original description:**
This PR introduces shared library (DSO) support for XRay based on a
revised version of the implementation outlined in [this
RFC](https://discourse.llvm.org/t/rfc-upstreaming-dso-instrumentation-support-for-xray/73000).
The feature enables the patching and handling of events from DSOs,
supporting both libraries linked at startup or explicitly loaded, e.g.
via `dlopen`.
This patch adds the following:
- The `-fxray-shared` flag to enable the feature (turned off by default)
- A small runtime library that is linked into every instrumented DSO,
providing position-independent trampolines and code to register with the
main XRay runtime
- Changes to the XRay runtime to support management and patching of
multiple objects
These changes are fully backward compatible, i.e. running without
instrumented DSOs will produce identical traces (in terms of recorded
function IDs) to the previous implementation.
Due to my limited ability to test on other architectures, this feature
is only implemented and tested with x86_64. Extending support to other
architectures is fairly straightforward, requiring only a
position-independent implementation of the architecture-specific
trampoline implementation (see
`compiler-rt/lib/xray/xray_trampoline_x86_64.S` for reference).
This patch does not include any functionality to resolve function IDs
from DSOs for the provided logging/tracing modes. These modes still work
and will record calls from DSOs, but symbol resolution for these
functions in not available. Getting this to work properly requires
recording information about the loaded DSOs and should IMO be discussed
in a separate RFC, as there are mulitple feasible approaches.
---------
Co-authored-by: Sebastian Kreutzer <sebastian.kreutzer@tu-darmstadt.de>
Currently, WebAssembly/WASI target does not provide direct support for
code coverage.
This patch set fixes several issues to unlock the feature. The main
changes are:
1. Port `compiler-rt/lib/profile` to WebAssembly/WASI.
2. Adjust profile metadata sections for Wasm object file format.
- [CodeGen] Emit `__llvm_covmap` and `__llvm_covfun` as custom sections
instead of data segments.
- [lld] Align the interval space of custom sections at link time.
- [llvm-cov] Copy misaligned custom section data if the start address is
not aligned.
- [llvm-cov] Read `__llvm_prf_names` from data segments
3. [clang] Link with profile runtime libraries if requested
See each commit message for more details and rationale.
This is part of the effort to add code coverage support in Wasm target
of Swift toolchain.
This PR introduces shared library (DSO) support for XRay based on a
revised version of the implementation outlined in [this
RFC](https://discourse.llvm.org/t/rfc-upstreaming-dso-instrumentation-support-for-xray/73000).
The feature enables the patching and handling of events from DSOs,
supporting both libraries linked at startup or explicitly loaded, e.g.
via `dlopen`.
This patch adds the following:
- The `-fxray-shared` flag to enable the feature (turned off by default)
- A small runtime library that is linked into every instrumented DSO,
providing position-independent trampolines and code to register with the
main XRay runtime
- Changes to the XRay runtime to support management and patching of
multiple objects
These changes are fully backward compatible, i.e. running without
instrumented DSOs will produce identical traces (in terms of recorded
function IDs) to the previous implementation.
Due to my limited ability to test on other architectures, this feature
is only implemented and tested with x86_64. Extending support to other
architectures is fairly straightforward, requiring only a
position-independent implementation of the architecture-specific
trampoline implementation (see
`compiler-rt/lib/xray/xray_trampoline_x86_64.S` for reference).
This patch does not include any functionality to resolve function IDs
from DSOs for the provided logging/tracing modes. These modes still work
and will record calls from DSOs, but symbol resolution for these
functions in not available. Getting this to work properly requires
recording information about the loaded DSOs and should IMO be discussed
in a separate RFC, as there are mulitple feasible approaches.
@petrhosek @jplehr
In a `runtimes` build on Solaris/amd64, there are two failues:
```
AddressSanitizer-Unit :: ./Asan-i386-calls-Dynamic-Test/failed_to_discover_tests_from_gtest
AddressSanitizer-Unit :: ./Asan-i386-inline-Dynamic-Test/failed_to_discover_tests_from_gtest
```
This happens when `lit` enumerates the tests with `--gtest_list_tests
--gtest_filter=-*DISABLED_*`. The error is twofold:
- The `LD_LIBRARY_PATH*` variables point at the 64-bit directory
(`lib/clang/19/lib/x86_64-pc-solaris2.11`) for a 32-bit test:
```
ld.so.1: Asan-i386-calls-Dynamic-Test: fatal:
/var/llvm/local-amd64-release-stage2-A-flang-clang18-runtimes/tools/clang/stage2-bins/./lib/../lib/clang/19/lib/x86_64-pc-solaris2.11/libclang_rt.asan.so:
wrong ELF class: ELFCLASS64
```
- While the tests are linked with `-Wl,-rpath`, that path always is the
64-bit directory again.
Accordingly, the fix consists of two parts:
- The code in `compiler-rt/test/asan/Unit/lit.site.cfg.py.in` to adjust
the `LD_LIBRARY_PATH*` variables is guarded by a `config.target_arch !=
config.host_arch` condition. This is wrong in two ways:
- The adjustment is always needed independent of the host arch. This is
what `compiler-rt/test/lit.common.cfg.py` already does.
- Besides, `config.host_arch` is ultimately set from
`CMAKE_HOST_SYSTEM_PROCESSOR`. On Linux/x86_64, this is `x86_64` (`uname
-m`) while on Solaris/amd64 it's `i386` (`uname -p`), explaining why the
transformation is skipped on Solaris, but not on Linux.
- Besides, `RPATH` needs to be set to the correct subdirectory, so
instead of using the default arch in `compiler-rt/CMakeLists.txt`, this
patch moves the code to a function which takes the test's arch into
account.
Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
Some failures in Rtsan-aarch64-NoInstTest have been reported.
This reverts commit ed17431bf7489c87ea81a6a67af5c7c206da0080.
This reverts commit b81fcd01bde51eb8976b81a2c0c19fc0645cd2ff.
Follow on to #92460 (reporting old android builds failing) and #98264
(powerpc failing to discover gtests).
Getting back to stability by getting back down to a very basic set of
supported arches and OS's. In the future if there is demand we can build
it back up. Especially when I understand how to test these systems, or
have people who want to do the work on them.
---------
Co-authored-by: David Trevelyan <david.trevelyan@gmail.com>
Follow up to #92460
DEPS llvm_gtest is not used by compiler-rt,
compiler-rt compiles them with COMPILER_RT_GOOGLETEST_SOURCES.
This reverts commit e217f98ac3ee55755ee6ea3b97551cf8283528c9.
Introducing the main runtime of realtime sanitizer. For more
information, please see the [discourse
thread](https://discourse.llvm.org/t/rfc-nolock-and-noalloc-attributes/76837).
We have also put together a [reviewer support
document](https://github.com/realtime-sanitizer/radsan/blob/doc/review-support/doc/review.md)
to show what our intention is.
This review introduces the sanitizer backend. This includes:
* CMake build files (largely adapted from asan).
* Main RTSan architecture (the external API, thread local context,
stack).
* Interceptors.
* Many unit tests.
Please see the [reviewer support
document](https://github.com/realtime-sanitizer/radsan/blob/doc/review-support/doc/review.md)
for what our next steps are. We are moving in lockstep with this PR
#84983 for the codegen coming up next.
Note to reviewers: If you see support documentation mention "RADSan",
this was the "old acronym" for the realtime sanitizer, they refer to the
same thing. If you see it let us know and we can correct it (especially
in the llvm codebase)
---------
Co-authored-by: David Trevelyan <david.trevelyan@gmail.com>
This diff contains the compiler-rt changes / preparations for nsan.
Test plan:
1. cd build/runtimes/runtimes-bins && ninja check-nsan
2. ninja check-all
This reverts commit fe82a3da36196157c0caa1ef2505186782f750d1.
This broke LLDB on MacOS due to a missing symbol during linking.
The fix has been applied in c6c08eee37bada190bd1aa4593c88a5e2c8cdaac.
Original commit message:
The terminfo dependency introduces a significant nonhermeticity into the
build. It doesn't respect `--no-undefined-version` meaning that it's not
a dependency that can be built with Clang 17+. This forces maintainers
of source-based distributions to implement patches or ignore linker
errors.
Remove it to reduce the closure size and improve portability of
LLVM-based tools. Users can still use command line arguments to toggle
color support expliticly.
Fixes#75490Closes#53294#23355
The terminfo dependency introduces a significant nonhermeticity into the
build. It doesn't respect `--no-undefined-version` meaning that it's not
a dependency that can be built with Clang 17+. This forces maintainers
of source-based distributions to implement patches or ignore linker
errors.
Remove it to reduce the closure size and improve portability of
LLVM-based tools. Users can still use command line arguments to toggle
color support expliticly.
Fixes#75490Closes#53294#23355
`__sanitizer_siginfo` has been introduced in D142117.
(llvmorg-16-init-17950-ged9ef9b4f248)
It is incompatible to -pedantic.
`clang_rt.ctx_profile` has been introduced in #92456.
As discussed here:
https://github.com/llvm/llvm-project/pull/74394#issuecomment-2035264683
An unintentional change of behavior was introduced in #74394
This code introduced in #74394 :
The first time through
* SANITIZER_MIN_OSX_VERSION is not set
* parse -mmacosx-version-min and set MACOSX_VERSION_MIN_FLAG
* Set and cache SANITIZER_MIN_OSX_VERSION
Subsequent times through:
* SANITIZER_MIN_OSX_VERSION is cached
* (BUG!!) you don't parse -mmacosx-version-min, and don't set
MACOSX_VERSION_MIN_FLAG
MACOSX_VERSION_MIN_FLAG is used later in the file on this line:
63c925ca80/compiler-rt/cmake/config-ix.cmake (L517)
Hoisting this assignment outside the if block returns us to the previous
behavior before this commit, while maintaining the flexibility
introduced with the cache variable
This reverts commit d2b63ed0ca5c7eb3f8fc029e3a5705cf0ddab438. CI again.
Leading theory is bad interaction between cmake and buildbot, some guesses at PR86737
compiler-rt may depend on libc (memset etc). Likewise a libc built by
clang may depend on compiler-rt builtins.
This circular dependency doesn't matter much once they're both compiled.
The easy compilation order to build both from source is:
1. install libc headers somewhere
2. build compiler-rt builtins against those headers
3. build libc against compiler-rt builtins
This patch relaxes the cmake sanity check to pass without requiring a
libc library. That allows the above sequence to work. Otherwise one
needs to build a static libc, then use that to pass the compiler-rt
cmake check, then build a normal libc.
The greendragon was recently moved and now it runs on somewhat newer
macOS
version - which breaks some sanitizers tests
rdar://125052915
Co-authored-by: Mariusz Borsa <m_borsa@apple.com>
These checks have been broken since 6afe972195454a1110ed8d20c6f2a547e6366379.
The check_cxx_compiler_flag macro only takes two arguments and passing
three to it ends up calling
`cmake_check_compiler_flag(CXX "${_FLAG}" ${_RESULT})` with ${_FLAG}
equal to `-Werror` and the result variable being the actually tested
compiler flag.
I noticed this because some of the flags that I know should be supported
were being flagged as not supported. `--debug-trycompile` shows the
following surprising line in the generated CMakeLists.txt:
`add_definitions([==[-D-Wempty-body]==] [==[-Werror]==])` which then
results in the following error while running the check:
```
FAILED: CMakeFiles/cmTC_72736.dir/src.cxx.o
tmp/upstream-llvm-readonly/bin/clang++ -nodefaultlibs -std=c++17 -fcolor-diagnostics -D-Wempty-body -Werror -MD -MT CMakeFiles/cmTC_72736.dir/src.cxx.o -MF CMakeFiles/cmTC_72736.dir/src.cxx.o.d -o CMakeFiles/cmTC_72736.dir/src.cxx.o -c .../cmake-build-all-sanitizers/CMakeFiles/CMakeScratch/TryCompile-nyh3QR/src.cxx
In file included from <built-in>:450:
<command line>:1:9: error: macro name must be an identifier
1 | #define -Wempty-body 1
| ^
1 error generated.
```
It would be great if CMake could be a bit more helpful here so I've
filed https://gitlab.kitware.com/cmake/cmake/-/issues/25735.
See also https://reviews.llvm.org/D146920.
Reviewed By: nikic
Pull Request: https://github.com/llvm/llvm-project/pull/83779
It is desirable to be able to configure the `-mmacosx-version-min` flag
for the sanitizers, but this flag was never made a CACHE variable in
cmake.
By doing this, it will allow developers to select different minimum
versions, which results in different interceptors being enabled or
disabled on their platforms. This version can now persist between cmake
runs, so it can be remembered by cmake, and edited in the cache file.
Embedded Darwin platforms have generalized COMPILER_RT_ENABLE_<PLATFORM>
configuration settings, but currently 'osx' is always eabled on Darwin.
Add ORC_ENABLE_OSX to allow explicitly *disabling* the orc runtime for
macOS platform. This can be useful if you only want to build a specific
embedded platform. It would be nice to generalize this to handle other
compiler-rt projects (i.e. add COMPILER_RT_ENABLE_OSX), but would
require additional attention from each compiler-rt project.
Note: some tests currently only are configured for osx, so these are
disabled when osx is disabled.
Functions with these attributes will be automatically called before
main() or after main() exits gracefully. In glibc environments, the
constructor function is passed the same arguments as main(), so that
signature is allowed. In all other environments, we require the function
to accept no arguments and either return `void` or `int`. The functions
must use the C calling convention. In C++ language modes, the functions
cannot be a nonstatic member function, or a consteval function.
Additionally, these reuse the same priority logic as the init_priority
attribute which explicitly reserved priorty values <= 100 or > 65535. So
we now diagnose use of reserved priorities the same as we do for the
init_priority attribute, but we downgrade the error to be a warning
which defaults to an error to ease use for implementers like compiler-rt
or libc.
This relands a633a3761fcbd0799426cbf5fbd7794961080e43 with fixes.
Functions with these attributes will be automatically called before
main() or after main() exits gracefully. In glibc environments, the
constructor function is passed the same arguments as main(), so that
signature is allowed. In all other environments, we require the function
to accept no arguments and either return `void` or `int`. The functions
must use the C calling convention. In C++ language modes, the functions
cannot be a nonstatic member function, or a consteval function.
Additionally, these reuse the same priority logic as the init_priority
attribute which explicitly reserved priorty values <= 100 or > 65535. So
we now diagnose use of reserved priorities the same as we do for the
init_priority attribute, but we downgrade the error to be a warning
which defaults to an error to ease use for implementers like compiler-rt
or libc.
This relands b4435104ca3904529723b0673cc0f624cf8c54e6 with fixes.
If libc++ is available and should be used as the ubsan C++ ABI library,
the check for libc++ might fail if libc++ is a static library, as the
-nodefaultlibs flag inhibits a potential compiler default -lunwind.
Just like the -nodefaultlibs configuration tests for and manually adds a
bunch of compiler default libraries, look for -lunwind too.
This is a reland of #65912.
This reverts commit 64c0bddb7639dd4bfad73fbbc909ca739b84aa10.
This seems to run into errors on some buildbots; configure errors
out like this:
-- Looking for _Unwind_RaiseException in unwind
-- Looking for _Unwind_RaiseException in unwind - not found
CMake Error at /usr/share/cmake-3.25/Modules/CheckLibraryExists.cmake:71 (try_compile):
Only libraries may be used as try_compile or try_run IMPORTED
LINK_LIBRARIES. Got unwind of type UTILITY.
Call Stack (most recent call first):
/b/sanitizer-aarch64-linux-fuzzer/build/llvm-project/compiler-rt/cmake/config-ix.cmake:66 (check_library_exists)
/b/sanitizer-aarch64-linux-fuzzer/build/llvm-project/compiler-rt/CMakeLists.txt:281 (include)
If libc++ is available and should be used as the ubsan C++ ABI library,
the check for libc++ might fail if libc++ is a static library, as the
-nodefaultlibs flag inhibits a potential compiler default -lunwind.
Just like the -nodefaultlibs configuration tests for and manually adds a
bunch of compiler default libraries, look for -lunwind too.
This patch supports GNU ld on Solaris in addition to Solaris ld, the
default.
- Linker selection is dynamic: one can switch between Solaris ld and GNU ld
at runtime, with the default selectable with `-DCLANG_DEFAULT_LINKER`.
- Testcases have been adjusted to test both variants in case there are
differences.
- The `compiler-rt/cmake/config-ix.cmake` and
`llvm/cmake/modules/AddLLVM.cmake` changes to restrict the tests to
Solaris ld are necessary because GNU accepts unknown `-z` options, but
warns every time they are used, creating a lot of noise. Since there
seems to be no way to check for those warnings in
`llvm_check_compiler_linker_flag` or `llvm_check_compiler_linker_flag`, I
restrict the cmake tests to Solaris ld in the first place.
- The changes to `clang/test/Driver/hip-link-bundle-archive.hip` and
`flang/test/Driver/linker-flags.f90` are required when LLVM is built with
`-DCLANG_DEFAULT_LINKER=gld` on Solaris: `MSVC.cpp`
`visualstudio::Linker::ConstructJob` ultimately calls
`GetProgramPath("gld")`, resulting in a search for `gld`, which exists in
`/usr/bin/gld` on Solaris. With `-fuse-ld=`, this doesn't happen and the
expected `link` is returned.
- `compiler-rt/test/asan/TestCases/global-location-nodebug.cpp` needs to
enforce the Solaris ld, otherwise the test would `XPASS` with GNU ld
which has the `-S` semantics expected by the test.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11` with both
`-DCLANG_DEFAULT_LINKER=gld` and the default, and `x86_64-pc-linux-gnu`.
No regressions in either case.
Differential Revision: https://reviews.llvm.org/D85309
Moved setting supported architecture to parent cmake configuration files
so they can be read by both lib and test CMakeList.txt.
Fixed issue with check-asan-abi that did not filter for current host architecture
which caused x86_64 bots to run Arm64 tests.
Added x86_64 as a supported arch to the test cmake file.
rdar://110017569
Differential Revision: https://reviews.llvm.org/D151846
# Darwin Sanitizers Stable ABI
We wish to make it possible to include the AddressSanitizer (ASan) runtime implementation in OSes and for this we need a stable ASan ABI. Based on previous discussions about this topic, our understanding is that freezing the present ABI would impose an excessive burden on other sanitizer developers and for unrelated platforms. Therefore, we propose adding a secondary stable ABI for our use and anyone else in the community seeking the same. We believe that we can define a stable ABI with minimal burden on the community, expecting only to keep existing tests running and implementing stubs when new features are added. We are okay with trading performance for stability with no impact for existing users of ASan while minimizing the maintenance burden for ASan maintainers. We wish to commit this functionality to the LLVM project to maintain it there. This new and stable ABI will abstract away the implementation details allowing new and novel approaches to ASan for developers, researchers and others.
## Details
Rather than adding a lot of conditional code to the LLVM instrumentation phase, which would incur excessive complexity and maintenance cost of adding conditional code into all places that emit a runtime call, we propose a “shim” layer which will map the unstable ABI to the stable ABI:
* A static library (.a library) shim that maps the existing ASan ABI to a generalized, smaller and stable ABI. The library would implement the __asan functions and call into the new ABI. For example:
* `void __asan_load1(uptr p) { __asan_abi_loadn(p, 1, true); }`
* `void __asan_load2(uptr p) { __asan_abi_loadn(p, 2, true); }`
* `void __asan_noabort_load16(uptr p) { __asan_abi_loadn(p, 16, false); }`
* `void __asan_poison_cxx_array_cookie(uptr p) { __asan_abi_pac(p); }`
* This “shim” library would only be used by people who opt in: A compilation flag in the Clang driver will be used to gate the use of the stable ABI workflow.
* Utilize the existing ability for the ASan instrumentation to prefer runtime calls instead of inlined direct shadow memory accesses.
* Pursue (under the new driver flag) a better separation of abstraction and implementation with:
* LLVM instrumentation: Calling out for all poisoning, checking and unpoisoning.
* Runtime: Implementing the stable ABI and being responsible of implementation details of the shadow memory.
## Maintenance
Our aim is that the maintenance burden on the sanitizer developer community be negligible. Stable ABI tests will always pass for non-Darwin platforms. Changes to the existing ABI which would require a change to the shim have been infrequent as the ASan ABI is already relatively stable. Rarely, a change that impacts the contract between LLVM and the shim will occur. Among such foreseeable changes are: 1) changes to a function signature, 2) additions of new functions, or 3) deprecation of an existing function. Following are some examples of reasonable responses to those changes:
* Example: An existing ABI function is changed to return the input parameter on success or NULL on failure. In this scenario, a reasonable change to the shim would be to modify the function signature appropriately and to simply guess at a common-sense implementation.
* `uptr __asan_load1(uptr p) { __asan_abi_loadn(p, 1, true); return p; }`
* Example: An additional function is added for performance reasons. It has a very similar function signature to other similarly named functions and logically is an extension of that same pattern. In this case it would make sense to apply the same logic as the existing entry points:
* `void __asan_load128(uptr p) { __asan_abi_loadn(p, 128, true); }`
* Example: An entry point is added to the existing ABI for which there is no obvious stable ABI implementation: In this case, doing nothing in a no-op stub would be acceptable, assuming existing features of ASan can still work without an actual implementation of this new function.
* `void __asan_prefetch(uptr p) { }`
* Example: An entrypoint in the existing ABI is deprecated and/or deleted:
* (Delete the entrypoint from the shim.)
We’re looking for buy-in for this level of support.
(Note: Upon acceptance of the general concepts herein, we will add a controlling clang flag, cmake integration, contract for the stable ABI, and the appropriate test infrastructure.)
Reviewed By: eugenis, vitalybuka, MaskRay
Differential Revision: https://reviews.llvm.org/D143675
-Werror is redundant because CMake not only checks the
exit status, but also parses the output of try_compile.
-Wformat-security is a special case, because specifying it
without -Wformat causes gcc to emit a warning in a format
not recognized by CMake, which makes the check pass.
