__fixunstfti converts a long double (IBM double-double) to an unsigned 128 bit
integer. This patch enables it to handle a previously unhandled case in which
a negative low double may impact the result of the conversion.
Collaborated with @masoud.ataei and @renenkel.
Patch By: Baptiste Saleil
Differential Revision: https://reviews.llvm.org/D69193
Fallout from:
[clang] Report sanitizer blacklist as a dependency in cc1
Default blacklists are now passed via -fsanitize-system-blacklist from driver to cc1.
Add support for continuously syncing profile counter updates to a file.
The motivation for this is that programs do not always exit cleanly. On
iOS, for example, programs are usually killed via a signal from the OS.
Running atexit() handlers after catching a signal is unreliable, so some
method for progressively writing out profile data is necessary.
The approach taken here is to mmap() the `__llvm_prf_cnts` section onto
a raw profile. To do this, the linker must page-align the counter and
data sections, and the runtime must ensure that counters are mapped to a
page-aligned offset within a raw profile.
Continuous mode is (for the moment) incompatible with the online merging
mode. This limitation is lifted in https://reviews.llvm.org/D69586.
Continuous mode is also (for the moment) incompatible with value
profiling, as I'm not sure whether there is interest in this and the
implementation may be tricky.
As I have not been able to test extensively on non-Darwin platforms,
only Darwin support is included for the moment. However, continuous mode
may "just work" without modification on Linux and some UNIX-likes. AIUI
the default value for the GNU linker's `--section-alignment` flag is set
to the page size on many systems. This appears to be true for LLD as
well, as its `no_nmagic` option is on by default. Continuous mode will
not "just work" on Fuchsia or Windows, as it's not possible to mmap() a
section on these platforms. There is a proposal to add a layer of
indirection to the profile instrumentation to support these platforms.
rdar://54210980
Differential Revision: https://reviews.llvm.org/D68351
Summary:
Sometimes an allocation stack trace is not very informative. Provide a
way to replace it with a stack trace of the user's choice.
Reviewers: pcc, kcc
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69208
Summary:
The flag allows the user to specify a maximum allocation size that the
sanitizers will honor. Any larger allocations will return nullptr or
crash depending on allocator_may_return_null.
Reviewers: kcc, eugenis
Reviewed By: kcc, eugenis
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69576
Summary:
The hwasan interceptor ABI doesn't have interceptors for longjmp and setjmp.
This patch introduces them.
We require the size of the jmp_buf on the platform to be at least as large as
the jmp_buf in our implementation. To enforce this we compile
hwasan_type_test.cpp that ensures a compile time failure if this is not true.
Tested on both GCC and clang using an AArch64 virtual machine.
Reviewers: eugenis, kcc, pcc, Sanatizers
Reviewed By: eugenis, Sanatizers
Tags: #sanatizers, #llvm
Differential Revision: https://reviews.llvm.org/D69045
Patch By: Matthew Malcomson <matthew.malcomson@arm.com>
Do not add an lld dependency when this target does not exist. In this
case the system installation of lld is used (or whatever is detected
with -fuse-ld=lld by default).
Summary:
Right now all hwasan tests on Android are silently disabled because they
require "has_lld" and standalone compiler-rt can not (and AFAIK was
never able to) set it.
Reviewers: pcc
Subscribers: dberris, mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69405
Within the last two weeks, the Builtins-*-sunos :: clear_cache_test.c started to FAIL
on Solaris. Running it under truss shows
mmap(0x00000000, 128, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 0, 0) Err#22 EINVAL
_exit(1)
While there are several possible reasons mmap can return EINVAL on Solaris, it turns
out it's this one (from mmap(2)):
MAP_ANON was specified, but the file descriptor was not
-1.
And indeed even the Linux mmap(2) documents this as unportable:
MAP_ANONYMOUS
The mapping is not backed by any file; its contents are initial‐
ized to zero. The fd argument is ignored; however, some imple‐
mentations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is
specified, and portable applications should ensure this. The
This patch follows this advise. Tested on x86_64-pc-linux-gnu, amd64-pc-solaris2.11
and sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D68455
llvm-svn: 375490
Android links the unwinder library to every DSO. The problem is,
unwinder has global state, and hwasan implementation of personality
function wrapper happens to rub it the wrong way.
Switch the test to static libc++ as a temporary workaround.
llvm-svn: 375471
When the %m filename pattern is used, the filename is unique to each
image, so the cached value is wrong.
It struck me that the full filename isn't something that's recomputed
often, so perhaps it doesn't need to be cached at all. David Li pointed
out we can go further and just hide lprofCurFilename. This may regress
workflows that depend on using the set-filename API to change filenames
across all loaded DSOs, but this is expected to be very rare.
rdar://55137071
Differential Revision: https://reviews.llvm.org/D69137
llvm-svn: 375301
Summary:
This has been an experiment with late malloc interposition, made
possible by a non-standard feature of the Android dynamic loader.
Reviewers: pcc, mmalcomson
Subscribers: srhines, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69199
llvm-svn: 375296
This is a follow up to r375150 to unbreak the `clang-ppc64be-linux` bot.
The commit caused running the tests to fail due to
```
llvm-lit:
/home/buildbots/ppc64be-clang-multistage-test/clang-ppc64be-multistage/llvm/projects/compiler-rt/test/builtins/Unit/lit.cfg.py:116:
fatal: builtins_source_features contains duplicates:
['librt_has_divtc3']
```
This commit should be reverted once the build system bug for powerpc is
fixed.
llvm-svn: 375162
Summary:
If a platform removes some builtin implementations (e.g. via the
Darwin-excludes mechanism) then this can lead to test failures because
the test expects an implementation to be available.
To solve this lit features are added for each configuration based
on which sources are included in the builtin library. The features
are of the form `librt_has_<name>` where `<name>` is the name of the
source file with the file extension removed. This handles C and
assembly sources.
With the lit features in place it is possible to make certain tests
require them.
Example:
```
REQUIRES: librt_has_comparedf2
```
All top-level tests in `test/builtins/Unit` (i.e. not under
`arm`, `ppc`, and `riscv`) have been annotated with the appropriate
`REQUIRES: librt_has_*` statement.
rdar://problem/55520987
Reviewers: beanz, steven_wu, arphaman, dexonsmith, phosek, thakis
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D68064
llvm-svn: 375150
After r375041 llvm-symbolizer uses it for demangling instead of
UnDecorateSymbolName. LLVM puts spaces after commas while Microsoft does
not.
llvm-svn: 375147
Updated: Removed offending TODO comment.
Dereferences with addresses above the 48-bit hardware addressable range
produce "invalid instruction" (instead of "invalid access") hardware
exceptions (there is no hardware address decoding logic for those bits),
and the address provided by this exception is the address of the
instruction (not the faulting address). The kernel maps the "invalid
instruction" to SEGV, but fails to provide the real fault address.
Because of this ASan lies and says that those cases are null
dereferences. This downgrades the severity of a found bug in terms of
security. In the ASan signal handler, we can not provide the real
faulting address, but at least we can try not to lie.
rdar://50366151
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D68676
> llvm-svn: 374265
llvm-svn: 374384
- Available from 12.x branch, by the time it lands next year in FreeBSD tree, the 11.x's might be EOL.
- Intentionally changed the getrandom test to C code as with 12.0 (might be fixed in CURRENT since), there is a linkage issue in C++ context.
Reviewers: emaste, dim, vitalybuka
Reviewed-By: vitalybuka
Differential Revision: https://reviews.llvm.org/D68451
llvm-svn: 374315
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
Dereferences with addresses above the 48-bit hardware addressable range
produce "invalid instruction" (instead of "invalid access") hardware
exceptions (there is no hardware address decoding logic for those bits),
and the address provided by this exception is the address of the
instruction (not the faulting address). The kernel maps the "invalid
instruction" to SEGV, but fails to provide the real fault address.
Because of this ASan lies and says that those cases are null
dereferences. This downgrades the severity of a found bug in terms of
security. In the ASan signal handler, we can not provide the real
faulting address, but at least we can try not to lie.
rdar://50366151
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D68676
llvm-svn: 374265
Summary:
It seems that compiler-rt's implementation and Darwin
libm's implementation of `logbf()` differ when given a NaN
with raised sign bit. Strangely this behaviour only happens with
i386 Darwin libm. For x86_64 and x86_64h the existing compiler-rt
implementation matched Darwin libm.
To workaround this the `compiler_rt_logbf_test.c` has been modified
to do a comparison on the `fp_t` type and if that fails check if both
values are NaN. If both values are NaN they are equivalent and no
error needs to be raised.
rdar://problem/55565503
Reviewers: rupprecht, scanon, compnerd, echristo
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D67999
llvm-svn: 374109
Jan Korous