Currently, SANITIZER_COMMON_SUPPORTED_OS is being used to enable many libraries.
Unfortunately this makes it impossible to selectively disable a library based on the OS.
This patch removes this limitation by adding a separate list of supported OSs for the lsan, ubsan, ubsan_minimal, and stats libraries.
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D113444
This fixes just a few of the warnings.
Ubsan is not completely clean yet,
but these somehow pop up while I was
fixing other sanitizers.
Depends on D107983.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107984
Enable -Wformat in sanitizer_common now that it's
cleaned up from existing warnings.
But disable it in all sanitizers for now since
they are not cleaned up yet, but inherit sanitizer_common CFLAGS.
Depends on D107980.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107981
InternalScopedString uses InternalMmapVector internally
so it can be resized dynamically as needed.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D98751
size() is inconsistent with length().
In most size() use cases we can replace InternalScopedString with
InternalMmapVector.
Remove non-constant data() to avoid direct manipulations of internal
buffer. append() should be enought to modify InternalScopedString.
Currently, `print_module_map` is only respected for ubsan if it is ran in tandem with asan. This patch adds support for this flag in standalone mode. I copied the pattern used to implement this for asan.
Also added a common `print_module_map` lit test for Darwin only. Since the print messages are different per platform, we need to write a regex test to cover them. This test is coming in a separate patch
rdar://56135732
Reviewed By: vitalybuka, vsk, delcypher
Differential Revision: https://reviews.llvm.org/D97746
/home/marxin/Programming/gcc2/libsanitizer/ubsan/ubsan_value.cpp:77:25: runtime error: left shift of 0x0000000000000000fffffffffffffffb by 96 places cannot be represented in type '__int128'
#0 0x7ffff754edfe in __ubsan::Value::getSIntValue() const /home/marxin/Programming/gcc2/libsanitizer/ubsan/ubsan_value.cpp:77
#1 0x7ffff7548719 in __ubsan::Value::isNegative() const /home/marxin/Programming/gcc2/libsanitizer/ubsan/ubsan_value.h:190
#2 0x7ffff7542a34 in handleShiftOutOfBoundsImpl /home/marxin/Programming/gcc2/libsanitizer/ubsan/ubsan_handlers.cpp:338
#3 0x7ffff75431b7 in __ubsan_handle_shift_out_of_bounds /home/marxin/Programming/gcc2/libsanitizer/ubsan/ubsan_handlers.cpp:370
#4 0x40067f in main (/home/marxin/Programming/testcases/a.out+0x40067f)
#5 0x7ffff72c8b24 in __libc_start_main (/lib64/libc.so.6+0x27b24)
#6 0x4005bd in _start (/home/marxin/Programming/testcases/a.out+0x4005bd)
Differential Revision: https://reviews.llvm.org/D97263
- Fixing VS compiler and other cases settings this time.
Reviewers: dmajor, hans
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D89759
Revert "Fix compiler-rt build on Windows after D89640"
This reverts commit a7acee89d6.
This reverts commit d09b08919c.
Reason: breaks Linux / x86_64 build.
D28596 added SANITIZER_INTERFACE_WEAK_DEF which can guarantee `*_default_options` are always defined.
The weak attributes on the `__{asan,lsan,msan,ubsan}_default_options` declarations can thus be removed.
`MaybeCall*DefaultOptions` no longer need nullptr checks, so their call sites can just be replaced by `__*_default_options`.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D87175
As requested in the review, this patch removes the additional conditions in
the `COMPILER_RT_HAS_VERSION_SCRIPT` tests.
Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D84559
Neither the Illumos `ld` nor the Solaris 11.3 one support the `--version-script` and
`z gnu-linker-script-compat` options, which breaks the `compiler-rt` build.
This patch checks for both options instead of hardcoding their use.
Tested on `amd-pc-solaris2.11` (all of Solaris 11.4, 11.3, and Illumos).
Differential Revision: https://reviews.llvm.org/D84559
I mistyped the ubsan objc_cast handler names on the first try.
Testing:
./bin/llvm-lit projects/compiler-rt/test/asan/X86_64HDarwinConfig/TestCases/Darwin/interface_symbols_darwin.cpp
Check that the implicit cast from `id` used to construct the element
variable in an ObjC for-in statement is valid.
This check is included as part of a new `objc-cast` sanitizer, outside
of the main 'undefined' group, as (IIUC) the behavior it's checking for
is not technically UB.
The check can be extended to cover other kinds of invalid casts in ObjC.
Partially addresses: rdar://12903059, rdar://9542496
Differential Revision: https://reviews.llvm.org/D71491
Create a sanitizer_ptrauth.h header that #includes <ptrauth> when
available and defines just the required macros as "no ops" otherwise.
This should avoid the need for excessive #ifdef'ing.
Follow-up to and discussed in: https://reviews.llvm.org/D79132
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D79540
Summary:
While working on rdar://problem/62083617 I noticed this call was
missing.
This is a no-op for all platforms except Darwin. For Darwin this
means the `use_xnu_fast_mmap` flag is initialized as it was intended
when using UBSan in standalone mode.
Reviewers: vitalybuka, vsk, kubamracek, yln, samsonov
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78532
Summary:
This fixes symbolization in Standalone UBSan mode for the Darwin simulators.
861b69faee (rdar://problem/58789439) tried to fix
symbolization for all sanitizers on Darwin simulators but unfortunately it only
fixed the problem for TSan.
For UBSan in standalone mode the fix wasn't sufficient because UBSan's
standalone init doesn't call `Symbolizer::LateInitialize()` like ASan
and TSan do. This meant that `AtosSymbolizerProcess::LateInitialize()`
was never being called before
`AtosSymbolizerProcess::StartSymbolizerSubprocess()` which breaks an
invariant we expect to hold.
The missing call to `Symbolizer::LateInitialize()` during UBSan's
standalone init seems like an accidently omission so this patch simply
adds it.
rdar://problem/62083617
Reviewers: vitalybuka, kubamracek, yln, samsonov
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78530
This variable is being used, but it's not being set (it's only set
for ubsan_minimal, but not ubsan). This addresses a regression that
was introduced in D78325.
Differential Revision: https://reviews.llvm.org/D78410
Summary:
Do not reexport libgcc.a symbols and random sanitizer internal symbols
by applying a version script to the shared library build.
This fixes unwinder conflicts on Android that are created by reexporting
the unwinder interface from libgcc_real.a. The same is already done in
asan and hwasan.
Reviewers: vitalybuka, srhines
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78325
Summary:
Quote from http://eel.is/c++draft/expr.add#4:
```
4 When an expression J that has integral type is added to or subtracted
from an expression P of pointer type, the result has the type of P.
(4.1) If P evaluates to a null pointer value and J evaluates to 0,
the result is a null pointer value.
(4.2) Otherwise, if P points to an array element i of an array object x with n
elements ([dcl.array]), the expressions P + J and J + P
(where J has the value j) point to the (possibly-hypothetical) array
element i+j of x if 0≤i+j≤n and the expression P - J points to the
(possibly-hypothetical) array element i−j of x if 0≤i−j≤n.
(4.3) Otherwise, the behavior is undefined.
```
Therefore, as per the standard, applying non-zero offset to `nullptr`
(or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value
from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined,
i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.)
To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer
is undefined, although Clang front-end pessimizes the code by not lowering
that info, so this UB is "harmless".
Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`)
LLVM middle-end uses those guarantees for transformations.
If the source contains such UB's, said code may now be miscompiled.
Such miscompilations were already observed:
* https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html
* https://github.com/google/filament/pull/1566
Surprisingly, UBSan does not catch those issues
... until now. This diff teaches UBSan about these UB's.
`getelementpointer inbounds` is a pretty frequent instruction,
so this does have a measurable impact on performance;
I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%),
and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark:
(all measurements done with LLVM ToT, the sanitizer never fired.)
* no sanitization vs. existing check: average `+21.62%` slowdown
* existing check vs. check after this patch: average `22.04%` slowdown
* no sanitization vs. this patch: average `48.42%` slowdown
Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers
Reviewed By: rsmith
Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits
Tags: #clang, #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67122
llvm-svn: 374293
Summary:
This option is true by default in sanitizer common. The default
false value was added a while ago without any reasoning in
524e934112
so, presumably it's safe to remove for consistency.
Reviewers: hctim, samsonov, morehouse, kcc, vitalybuka
Reviewed By: hctim, samsonov, vitalybuka
Subscribers: delcypher, #sanitizers, llvm-commits, kcc
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D67193
llvm-svn: 371442
See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran
for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done
and manually updated references to renamed files found by that.
llvm-svn: 367452
i.e., recent 5745eccef54ddd3caca278d1d292a88b2281528b:
* Bump the function_type_mismatch handler version, as its signature has changed.
* The function_type_mismatch handler can return successfully now, so
SanitizerKind::Function must be AlwaysRecoverable (like for
SanitizerKind::Vptr).
* But the minimal runtime would still unconditionally treat a call to the
function_type_mismatch handler as failure, so disallow -fsanitize=function in
combination with -fsanitize-minimal-runtime (like it was already done for
-fsanitize=vptr).
* Add tests.
Differential Revision: https://reviews.llvm.org/D61479
llvm-svn: 366186
This follows up after b7692bc3e9 "[UBSan] Fix
isDerivedFromAtOffset on iOS ARM64" fixed the RTTI comparison in
isDerivedFromAtOffset on just one platform and then
a25a2c7c9a "Always compare C++ typeinfo (based on
libstdc++ implementation)" extended that fix to more platforms.
But there is another RTTI comparison for -fsanitize=function generated in
clang's CodeGenFunction::EmitCall as just a pointer comparison. For
SANITIZER_NON_UNIQUE_TYPEINFO platforms this needs to be extended to also do
string comparison. For that, __ubsan_handle_function_type_mismatch[_abort]
takes the two std::type_info pointers as additional parameters now, checks them
internally for potential equivalence, and returns without reporting failure if
they turn out to be equivalent after all. (NORETURN needed to be dropped from
the _abort variant for that.) Also these functions depend on ABI-specific RTTI
now, so needed to be moved from plain UBSAN_SOURCES (ubsan_handlers.h/cc) to
UBSAN_CXXABI_SOURCES (ubsan_handlers_cxx.h/cc), but as -fsanitize=function is
only supported in C++ mode that's not a problem.
Differential Revision: https://reviews.llvm.org/D60760
llvm-svn: 359759
GetStackTrace is a implementation detail of BufferedStackTrace. Make it
a private method.
Reviewed By: vitalybuka
Differential-Revision: https://reviews.llvm.org/D58753
llvm-svn: 355232
Retrying without replacing call sites in sanitizer_common (which might
not have a symbol definition).
Add new Unwind API. This is the final envisioned API with the correct
abstraction level. It hides/slow fast unwinder selection from the caller
and doesn't take any arguments that would leak that abstraction (i.e.,
arguments like stack_top/stack_bottom).
GetStackTrace will become an implementation detail (private method) of
the BufferedStackTrace class.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D58741
> llvm-svn: 355168
llvm-svn: 355172
Add new Unwind API. This is the final envisioned API with the correct
abstraction level. It hides/slow fast unwinder selection from the caller
and doesn't take any arguments that would leak that abstraction (i.e.,
arguments like stack_top/stack_bottom).
GetStackTrace will become an implementation detail (private method) of
the BufferedStackTrace class.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D58741
llvm-svn: 355168
The concept of weak linkage is not available on Windows. The available
workarounds in LLVM/sanitizer runtimes have their own problems. Define a
separte symbol ubsan_GetStackTrace to work around the issue now. At lest
this way it is painfully obvious that we still have to do more cleanup.
Follow-up to revision: https://reviews.llvm.org/D58651
llvm-svn: 355113
Emily Shi