| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D69870
|
|
|
|
|
|
| |
coverage-fork.cpp uses `fork()` which requires additional permissions
in the iOS simulator sandbox. We cannot use `sandbox-exec` to grant
these permissions since this is a Posix (not Darwin) test.
|
|
|
|
|
|
|
|
| |
This is a patch to support D66328, which was reverted until this lands.
Enable a compiler-rt test that used to fail previously with D66328.
Differential Revision: https://reviews.llvm.org/D67283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously it wasn't obvious what the default value of various sanitizer
options were. A very close approximation of the "default values" for the
options are the current value of the options at the time of printing the
help output.
In the case that no other options are provided then the current values
are the default values (apart from `help`).
```
ASAN_OPTIONS=help=1 ./program
```
This patch causes the current option values to be printed when the
`help` output is enabled. The original intention for this patch was to append
`(Default: <value>)` to an option's help text. However because this
is technically wrong (and misleading) I've opted to append
`(Current Value: <value>)` instead.
When trying to implement a way of displaying the default value of the
options I tried another solution where the default value used in `*.inc` files
were used to create compile time strings that where used when printing
the help output. This solution was not satisfactory for several reasons:
* Stringifying the default values with the preprocessor did not work very
well in several cases. Some options contain boolean operators which no
amount of macro expansion can get rid of.
* It was much more invasive than this patch. Every sanitizer had to be changed.
* The settings of `__<sanitizer>_default_options()` are ignored.
For those reasons I opted for the solution in this patch.
rdar://problem/42567204
Reviewers: kubamracek, yln, kcc, dvyukov, vitalybuka, cryptoad, eugenis, samsonov
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fixes two problems with the crtbegin.c as written:
1. In do_init, register_frame_info is not guarded by a #define, but in
do_fini, deregister_frame_info is guarded by #ifndef
CRT_HAS_INITFINI_ARRAY. Thus when CRT_HAS_INITFINI_ARRAY is not
defined, frames are registered but then never deregistered.
The frame registry mechanism builds a linked-list from the .so's
static variable do_init.object, and when the .so is unloaded, this
memory becomes invalid and should be deregistered.
Further, libgcc's crtbegin treats the frame registry as independent
from the initfini array mechanism.
This patch fixes this by adding a new #define,
"EH_USE_FRAME_INFO_REGISTRY", which is set by the cmake option
COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY Currently, do_init calls
register_frame_info, and then calls the binary's constructors. This
allows constructors to safely use libunwind. However, do_fini calls
deregister_frame_info and then calls the binary's destructors. This
prevents destructors from safely using libunwind.
This patch also switches that ordering, so that destructors can safely
use libunwind. As it happens, this is a fairly common scenario for
thread sanitizer.
|
|
|
|
| |
This reverts commit d6be9273c6035c07b25dd1494f76cd61d523b878.
|
|
|
|
|
|
|
|
|
|
|
| |
__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
|
|
|
|
|
|
| |
This reverts commit bdeb2724f0aa9c518f94d998d24d8620a1e88727.
(Reverting 03b84e4f6d0, so this must come out as well)
|
|
|
|
|
|
|
| |
Fallout from:
[clang] Report sanitizer blacklist as a dependency in cc1
Default blacklists are now passed via -fsanitize-system-blacklist from driver to cc1.
|
|
|
|
| |
Fixes build of test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
error to a warning."
This reverts commit dc748816e2aec8941d63f8ad07fb82aff6be8af7.
Now that 8ea148dc0cbff33ac3c80cf4273991465479a01e has landed it should
be safe to turning the warning back into a fatal error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
"alocation-tail-overwritten" -> "allocation-tail-overwritten"
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This is more portable than -dynamiclib. Also, fix the path to an input
file that broke when the test was moved in r375315.
llvm-svn: 375317
|
|
|
|
|
|
|
| |
The Windows bots are failing with:
clang: warning: argument unused during compilation: '-dynamiclib' [-Wunused-command-line-argument]
llvm-svn: 375315
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
warning.
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an implementation is provided by a builtin library.
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
|
|
|
|
|
|
|
|
| |
devirtualization.
Differential Revision: https://reviews.llvm.org/D67985
llvm-svn: 374909
|
|
|
|
|
|
| |
A fix for r373993.
llvm-svn: 374448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dereferences"
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
|
|
|
|
| |
llvm-svn: 374333
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
| |
llvm-svn: 374309
|
|
|
|
|
|
|
|
|
|
| |
dereferences"
As it was breaking bots running sanitizer lint check
This reverts r374265 (git b577efe4567f1f6a711ad36e1d17280dd1c4f009)
llvm-svn: 374308
|
|
|
|
|
|
| |
I do not understand the BB failire, it fully passes locally.
llvm-svn: 374306
|
|
|
|
|
|
| |
make it pass on sanitizer-windows BB
llvm-svn: 374298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
behaviour
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
|
|
|
|
| |
llvm-svn: 374223
|
|
|
|
| |
llvm-svn: 374220
|
|
|
|
| |
llvm-svn: 374213
|
|
|
|
| |
llvm-svn: 374211
|
|
|
|
| |
llvm-svn: 374125
|
|
|
|
| |
llvm-svn: 374115
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 374088
|
|
|
|
| |
llvm-svn: 374010
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: vitalybuka
Subscribers: srhines, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D68431
llvm-svn: 373993
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: eugenis, jfb
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D68603
llvm-svn: 373979
|