Summary:
With the change, one can choose not to report comparison (or subtraction)
of a pointer with nullptr pointer.
Reviewers: kcc, jakubjelinek, alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D41479
llvm-svn: 323995
There was a failure on a bot:
http://lab.llvm.org:8011/builders/clang-cmake-mipsel/builds/1283
strerror test is indeed flaky. We protect all races by a barrier in other tests
to eliminate flakiness. Do the same here.
No idea why tls_race2.cc failed. Add output at the end of the test
as we do in other tests. Sometimes test process crashes somewhere
in the middle (e.g. during race reporting) and it looks like empty output.
Output at the end of test allows to understand if the process has crashed,
or it has finished but produced no race reports.
Reviewed in https://reviews.llvm.org/D42633
llvm-svn: 323657
This gets rid of a lit warning (input './projects/compiler-rt/test/xray/Unit' contained no tests).
Differential Revision: https://reviews.llvm.org/D42597
llvm-svn: 323613
In more recent Linux kernels with 47 bit VMAs the layout of virtual memory
for powerpc64 changed causing the address sanitizer to not work properly. This
patch fixes up a test case that was found to fail on some newer Fedora
releases that use different address ranges.
ref: https://reviews.llvm.org/D40907
llvm-svn: 323217
Summary:
One test-case uses a wrong operation (should be subtraction).
Second test-case should declare a global variables before a tested one
in order to guarantee we will find a red-zone.
Reviewers: kcc, jakubjelinek, alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D41481
llvm-svn: 323162
sequentially.
The current implementation of commands in
`test/sanitizer_common/ios_commands/` for iOS devices cannot be executed
in parallel which results in the ASan and TSan tests failing when
executed in parallel by lit which was the default behaviour.
We now force the ASan and TSan tests to be a new parallelism group named
`darwin-ios-device-sanitizer` which allows only one test to be run at a
time. We also emit a warning informing the user that tests are being
run sequentially.
This only applies if the target is an iOS device.
Differential Revision: https://reviews.llvm.org/D42156
llvm-svn: 323026
Summary:
Tests were being run by whole-linking the static library with our test binaries.
But since `-fsanitize=scudo` landed with rL317337, we might as well change how
the tests are compiled to use it.
The only difference will be on Android, where the clang flag links in the
dynamic library instead, but the bots are already pushing
`libclang_rt.*-android.so` to the device there is no additional change needed.
Tested locally, including with a standalone build, and an Android one on a O
device, and it all passes.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42243
llvm-svn: 322882
This is needed in case the users of libFuzzer use libc++ in their
code, which the fuzz target (libFuzzer) will be linked against.
When libc++ source is available, we build a private version of it
and link it against libFuzzer which allows using the same static
library against codebases which use both libc++ and libstdc++.
Differential Revision: https://reviews.llvm.org/D37631
llvm-svn: 322755
Summary:
This patch (on top of the previous two (https://reviews.llvm.org/D40898 and
https://reviews.llvm.org/D40899) complete the compiler-rt side of the the Solaris
sanitizer port.
It contains the following sets of changes:
* For the time being, the port is for 32-bit x86 only, so reject the various tests on
x86_64.
* When compiling as C++, <setjmp.h> resp. <iso/setjmp_iso.h> only declares
_setjmp and _longjmp inside namespace std.
* MAP_FILE is a Windows feature. While e.g. Linux <sys/mman.h> provides a
no-op compat define, Solaris does not.
* test/asan/TestCases/Posix/coverage.cc was initially failing like this:
/vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/sanitizer_common/scripts/sancov.py: 4 files merged; 2 PCs total
rm: cannot remove '/var/gcc/llvm/local/projects/compiler-rt/test/asan/I386SunOSConfig/TestCases/Posix/Output/coverage': Invalid argument
Further digging revealed that the rm was trying to remove the running test's working
directory which failed as observed. cd'ing out of the dir before let the test pass.
* Two tests needed a declaration of alloca. I've now copied the existing code from
test/asan/TestCases/alloca_constant_size.cc, but it may be more profitable and
maintainable to have a common testsuite header where such code is collected.
* Similarly, Solaris' printf %p format doesn't include the leading 0x.
* In test/asan/TestCases/malloc-no-intercept.c, I had to undef __EXTENSIONS__
(predefined by clang for no apparent reason) to avoid conflicting declarations
for memalign.
* test/ubsan/TestCases/Float/cast-overflow.cpp has different platform dependent
ways to define BYTE_ORDER and friends. Why not just use __BYTE_ORDER__ and
friends as predefined by clang and gcc?
Patch by Rainer Orth.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, mgorny, krytarowski, fedor.sergeev, JDevlieghere, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40900
llvm-svn: 322635
This is needed in case the users of libFuzzer use libc++ in their
code, which the fuzz target (libFuzzer) will be linked against.
When libc++ source is available, we build a private version of it
and link it against libFuzzer which allows using the same static
library against codebases which use both libc++ and libstdc++.
Differential Revision: https://reviews.llvm.org/D37631
llvm-svn: 322604
Summary:
Very basic stack instrumentation using tagged pointers.
Tag for N'th alloca in a function is built as XOR of:
* base tag for the function, which is just some bits of SP (poor
man's random)
* small constant which is a function of N.
Allocas are aligned to 16 bytes. On every ReturnInst allocas are
re-tagged to catch use-after-return.
This implementation has a bunch of issues that will be taken care of
later:
1. lifetime intrinsics referring to tagged pointers are not
recognized in SDAG. This effectively disables stack coloring.
2. Generated code is quite inefficient. There is one extra
instruction at each memory access that adds the base tag to the
untagged alloca address. It would be better to keep tagged SP in a
callee-saved register and address allocas as an offset of that XOR
retag, but that needs better coordination between hwasan
instrumentation pass and prologue/epilogue insertion.
3. Lifetime instrinsics are ignored and use-after-scope is not
implemented. This would be harder to do than in ASan, because we
need to use a differently tagged pointer depending on which
lifetime.start / lifetime.end the current instruction is dominated
/ post-dominated.
Reviewers: kcc, alekseyshl
Subscribers: srhines, kubamracek, javed.absar, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41602
llvm-svn: 322324
Summary:
Enable the compile-time flag -fsanitize-memory-use-after-dtor by
default. Note that the run-time option MSAN_OPTIONS=poison_in_dtor=1
still needs to be enabled for destructors to be poisoned.
Reviewers: eugenis, vitalybuka, kcc
Reviewed By: eugenis, vitalybuka
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D37860
llvm-svn: 322221
Summary:
Avoid flaky test failures by by using a monotonic number sequence of
heap tags.
Does not affect stack tags: the way we generate those guarantees
uniqueness for at least 30-something first allocas in any function,
as well as the UAR tag.
Reviewers: alekseyshl, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D41882
llvm-svn: 322214
As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/
#!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non-
noexcept pointer is undefined behavior?", such a call should not be UB.
However, Clang currently warns about it.
This change removes exception specifications from the function types recorded
for -fsanitize=function, both in the functions themselves and at the call sites.
That means that calling a non-noexcept function through a noexcept pointer will
also not be flagged as UB. In the review of this change, that was deemed
acceptable, at least for now. (See the "TODO" in compiler-rt
test/ubsan/TestCases/TypeCheck/Function/function.cpp.)
This is the compiler-rt part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40720
llvm-svn: 321860
Summary:
It used to fail on the bots, but I could not repro it locally. So turn it back
on to try and see if it still fails and maybe get to the heart of it.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: aemerson, srhines, kristof.beyls, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D41707
llvm-svn: 321812
Summary: Extend the sendmsg test to cover all recv*.
Reviewers: vitalybuka
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D41620
llvm-svn: 321774
...when such an operation is done on an object during con-/destruction.
(This adds a test case to compiler-rt/test/ubsan/TestCases/TypeCheck/vptr.cpp
that, unlike the existing test cases there, wants to detect multiple UBSan
warnings in one go. Therefore, that file had to be changed from globally using
-fno-sanitize-recover to individually using halt_on_error only where
appropriate.)
This is the compiler-rt part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40295
llvm-svn: 321518
Summary:
Export aligned new/delete to make dynamic runtimes work again.
Remove all valid new/delete cases from ASan test, there's a test in
common for that.
Reviewers: eugenis
Subscribers: srhines, kubamracek, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41548
llvm-svn: 321394
Summary:
Providing aligned new/delete implementations to match ASan.
Unlike ASan, MSan and TSan do not perform any additional checks
on overaligned memory, hence no sanitizer specific tests.
Reviewers: eugenis
Subscribers: kubamracek, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41532
llvm-svn: 321365
Summary: Very similar to AddressSanitizer, with the exception of the error type encoding.
Reviewers: kcc, alekseyshl
Subscribers: cfe-commits, kubamracek, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D41417
llvm-svn: 321203
There could be a situation when a specific DSO was built with FORTIFY_SOURCE option. In case asan-ed binary link against that DSO,
libasan can't handle the possible memory error because it does not have interceptors for spinrtf_chk, snprintf_chk, vprintf_chk,
vsnprintf_chk, __fprintf_chk functions. Let's interceptors for them.
Patch by Denis Khalikov.
Differential Revision: https://reviews.llvm.org/D40951
llvm-svn: 320990
At least <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/
builds/6013/steps/annotate/logs/stdio> complains about
__ubsan::__ubsan_handle_function_type_mismatch_abort (compiler-rt
lib/ubsan/ubsan_handlers.cc) returning now despite being declared 'noreturn', so
looks like a different approach is needed for the function_type_mismatch check
to be called also in cases that may ultimately succeed.
llvm-svn: 320981
As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/
#!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non-
noexcept pointer is undefined behavior?", such a call should not be UB.
However, Clang currently warns about it.
There is no cheap check whether two function type_infos only differ in noexcept,so pass those two type_infos as additional data to the function_type_mismatch
handler (with the optimization of passing a null "static callee type" info when that is already noexcept, so the additional check can be avoided anyway). For
the Itanium ABI (which appears to be the only one that happens to be used on
platforms that support -fsanitize=function, and which appears to only record
noexcept information for pointer-to-function type_infos, not for function
type_infos themselves), we then need to check the mangled names for occurrence
of "Do" representing "noexcept".
This is the compiler-rt part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40720
llvm-svn: 320977
This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).
Hopefully the Windows support is fixed now.
Patch by Rainer Orth!
Differential Revision: https://reviews.llvm.org/D40944
llvm-svn: 320731
This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).
Patch by Rainer Orth!
Differential Revision: https://reviews.llvm.org/D40944
llvm-svn: 320726
Summary:
Before this change, XRay would conservatively patch sections of the code
one sled at a time. Upon testing/profiling, this turns out to take an
inordinate amount of time and cycles. For an instrumented clang binary,
the cycles spent both in the patching/unpatching routine constituted 4%
of the cycles -- this didn't count the time spent in the kernel while
performing the mprotect calls in quick succession.
With this change, we're coalescing the number of calls to mprotect from
being linear to the number of instrumentation points, to now being a
lower constant when patching all the sleds through `__xray_patch()` or
`__xray_unpatch()`. In the case of calling `__xray_patch_function()` or
`__xray_unpatch_function()` we're now doing an mprotect call once for
all the sleds for that function (reduction of at least 2x calls to
mprotect).
Reviewers: kpw, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41153
llvm-svn: 320664
Summary:
The first and only function to start with allows to set the soft or hard RSS
limit at runtime. Add associated tests.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: mgorny, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41128
llvm-svn: 320611
Summary: This brings CPU overhead on bzip2 down from 5.5x to 2x.
Reviewers: kcc, alekseyshl
Subscribers: kubamracek, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41137
llvm-svn: 320538
This also slightly refactors the code that's checking the directory
presence which allows eliminating one unnecessary variable.
Differential Revision: https://reviews.llvm.org/D40637
llvm-svn: 320446
Summary:
This tests must be linked with -lintl for the gettext(3) features.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D41013
llvm-svn: 320226
Summary:
This test uses GNU-specific extension to libc: tdestroy() and as-is is not compatible with NetBSD.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D41011
llvm-svn: 320225
In more recent Linux kernels with 47 bit VMAs the layout of virtual memory
for powerpc64 changed causing the address sanitizer to not work properly. This
patch adds support for 47 bit VMA kernels for powerpc64 and fixes up test
cases.
https://reviews.llvm.org/D40908
There is an associated patch for trunk.
Tested on several 4.x and 3.x kernel releases.
llvm-svn: 320110
Summary:
This change implements the basic mode filtering similar to what we do in
FDR mode. The implementation is slightly simpler in basic-mode filtering
because we have less details to remember, but the idea is the same. At a
high level, we do the following to decide when to filter function call
records:
- We maintain a per-thread "shadow stack" which keeps track of the
XRay instrumented functions we've encountered in a thread's
execution.
- We push an entry onto the stack when we enter an XRay instrumented
function, and note the CPU, TSC, and type of entry (whether we have
payload or not when entering).
- When we encounter an exit event, we determine whether the function
being exited is the same function we've entered recently, was
executing in the same CPU, and the delta of the recent TSC and the
recorded TSC at the top of the stack is less than the equivalent
amount of microseconds we're configured to ignore -- then we un-wind
the record offset an appropriate number of times (so we can
overwrite the records later).
We also support limiting the stack depth of the recorded functions,
so that we don't arbitrarily write deep function call stacks.
Reviewers: eizan, pelikan, kpw, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40828
llvm-svn: 319762
Summary:
This change allows for registration of multiple logging implementations
through a central mechanism in XRay, mapping an implementation to a
"mode". Modes are strings that are used as keys to determine which
implementation to install through a single API. This mechanism allows
users to choose which implementation to install either from the
environment variable 'XRAY_OPTIONS' with the `xray_mode=` flag, or
programmatically using the `__xray_select_mode(...)` function.
Here, we introduce two API functions for the XRay logging:
__xray_log_register_mode(Mode, Impl): Associates an XRayLogImpl to a
string Mode. We can only have one implementation associated with a given
Mode.
__xray_log_select_mode(Mode): Finds the associated Impl for Mode and
installs it as if by calling `__xray_set_log_impl(...)`.
Along with these changes, we also deprecate the xray_naive_log and
xray_fdr_log flags and encourage users to instead use the xray_mode
flag.
Reviewers: kpw, dblaikie, eizan, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40703
llvm-svn: 319759
Following patch adds support of all memory origins in
CheckForInvalidPointerPair function. For small difference of pointers,
it's directly done in shadow memory (the limit was set to 2048B).
Then we search for origin of first pointer and verify that the second
one has the same origin. If so, we verify that it points either to a same
variable (in case of stack memory or a global variable), or to a same
heap segment.
Committing on behanf of marxin and jakubjelinek.
Reviewers: alekseyshl, kcc
Subscribers: llvm-commits
Differential revision: https://reviews.llvm.org/D40600
llvm-svn: 319668
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
The original attempt, r319525 was reverted in r319526 due
to the failures in compiler-rt standalone builds.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
llvm-svn: 319575
This reverts commit r319525.
This change has introduced a problem with the Lit tests build for compiler-rt using Gold: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/6047/steps/test%20standalone%20compiler-rt/logs/stdio
llvm-lit: /b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py:101: fatal: unable to parse config file '/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg', traceback: Traceback (most recent call last):
File "/b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py", line 88, in load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 37, in <module>
if root.host_os not in ['Linux'] or not is_gold_linker_available():
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 27, in is_gold_linker_available
stderr = subprocess.PIPE)
File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
llvm-svn: 319529
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
llvm-svn: 319525
On macOS, we usually don't require launching the target with DYLD_INSERT_LIBRARIES anymore. However, it is still necessary when running a target that is not instrumented (and e.g. dlopen's an instrument library later). In any case, ASan and TSan currently remove themselves from the DYLD_INSERT_LIBRARIES environment variable to avoid passing it onto children. This works well e.g. when instrumenting a shell. A problem arises when the target is a non-instrumented shim (e.g. "xcrun") that either re-execs or launches a child that is supposed to get DYLD_INSERT_LIBRARIES propagated. To support this mode, this patch introduces 'strip_env' flag that can be used to keep DYLD_INSERT_LIBRARIES untouched.
Differential Revision: https://reviews.llvm.org/D39991
llvm-svn: 319365
It's explicitly forbidden to call fclose with NULL, but at least on Darwin, this succeeds and doesn't segfault. To maintain binary compatibility, ASan should survice fclose(NULL) as well.
Differential Revision: https://reviews.llvm.org/D40053
llvm-svn: 319347
Calling getpwnam(NULL) is probably a bug, but at least on Darwin, such a call succeeds without segfaulting. I have some existing code that relies on that. To maintain binary compatibility, ASan should also survive a call to getpwnam with NULL.
Differential Revision: https://reviews.llvm.org/D40052
llvm-svn: 319344
Summary:
Before this patch, XRay's basic (naive mode) logging would be
initialised and installed in an adhoc manner. This patch ports the
implementation of the basic (naive mode) logging implementation to use
the common XRay framework.
We also make the following changes to reduce the variance between the
usage model of basic mode from FDR (flight data recorder) mode:
- Allow programmatic control of the size of the buffers dedicated to
per-thread records. This removes some hard-coded constants and turns
them into runtime-controllable flags and through an Options
structure.
- Default the `xray_naive_log` option to false. For now, the only way
to start basic mode is to set the environment variable, or set the
default at build-time compiler options. Because of this change we've
had to update a couple of tests relying on basic mode being always
on.
- Removed the reliance on a non-trivially destructible per-thread
resource manager. We use a similar trick done in D39526 to use
pthread_key_create() and pthread_setspecific() to ensure that the
per-thread cleanup handling is performed at thread-exit time.
We also radically simplify the code structure for basic mode, to move
most of the implementation in the `__xray` namespace.
Reviewers: pelikan, eizan, kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40164
llvm-svn: 318734
PDB emission now works well enough that we can rely on it for these
tests to pass.
Differential Revision: https://reviews.llvm.org/D40188
llvm-svn: 318546
The tests are ported as follows:
contiguous_container_crash.cc
use-after-delete.cc
use-after-free.cc
Replace hardwired shadow granularity in CHECK statements with regex.
max_redzone.cc
Bump max_redzone parameter to 32.
memset_test.cc
Bump size parameter of __asan_poison_memory_region to 32.
scariness_score_test.cc
For "far-from-bounds" heap overflow, make sure overflow is more than
one shadow granularity away.
At large shadow granularity, there is not enough redzone between
stack elements to detect far-from-bounds, so fake out that test.
Differential Revision: https://reviews.llvm.org/D39773
llvm-svn: 318470
The mulsc3_test.c was marked as unsupported due to PR32457, the underlying
cause of this PR was fixed in PR28164 so we can remove the unsupported as
it is no longer needed.
Differential Revision: https://reviews.llvm.org/D40076
llvm-svn: 318396
Summary:
This implements an opportunistic check for the RSS limit.
For ASan, this was implemented thanks to a background thread checking the
current RSS vs the set limit every 100ms. This was deemed problematic for Scudo
due to potential Android concerns (Zygote as pointed out by Aleksey) as well as
the general inconvenience of having a permanent background thread.
If a limit (soft or hard) is specified, we will attempt to update the RSS limit
status (exceeded or not) every 100ms. This is done in an opportunistic way: if
we can update it, we do it, if not we return the current status, mostly because
we don't need it to be fully consistent (it's done every 100ms anyway). If the
limit is exceeded `allocate` will act as if OOM for a soft limit, or just die
for a hard limit.
We use the `common_flags()`'s `hard_rss_limit_mb` & `soft_rss_limit_mb` for
configuration of the limits.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40038
llvm-svn: 318301
Summary:
This change fixes the XRay trampolines aside from the __xray_CustomEvent
trampoline to align the stack to 16-byte boundaries before calling the
handler. Before this change we've not been explicitly aligning the stack
to 16-byte boundaries, which makes it dangerous when calling handlers
that leave the stack in a state that isn't strictly 16-byte aligned
after calling the handlers.
We add a test that makes sure we can handle these cases appropriately
after the changes, and prevents us from regressing the state moving
forward.
Fixes http://llvm.org/PR35294.
Reviewers: pelikan, pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40004
llvm-svn: 318261
Allow user to override shadow scale in compiler_rt by passing
-DCOMPILER_RT_ASAN_SHADOW_SCALE=n to CMake. Propagate the override
shadow scale value via a compiler define to compiler-rt and asan
tests. Tests will use the define to partially disable unsupported
tests. Set "-mllvm -asan-mapping-scale=<n>" for compiler_rt tests.
Differential Revision: https://reviews.llvm.org/D39469
llvm-svn: 318038
Multi-config CMake generators need lit to be able to resolve paths of
artifacts from previous build steps at lit time, rather than expect them
to be fully resolved at CMake time as they may contain the build mode.
Differential Revision: https://reviews.llvm.org/D38471
llvm-svn: 318037
If the lookup using RTLD_NEXT failed, the sanitizer runtime library
is later in the library search order than the DSO that we are trying
to intercept, which means that we cannot intercept this function. We
still want the address of the real definition, though, so look it up
using RTLD_DEFAULT.
Differential Revision: https://reviews.llvm.org/D39779
llvm-svn: 317930
Summary:
This change implements the changes required in both clang and
compiler-rt to allow building XRay-instrumented binaries in Darwin. For
now we limit this to x86_64. We also start building the XRay runtime
library in compiler-rt for osx.
A caveat to this is that we don't have the tests set up and running
yet, which we'll do in a set of follow-on changes.
This patch uses the monorepo layout for the coordinated change across
multiple projects.
Reviewers: kubamracek
Subscribers: mgorny, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D39114
llvm-svn: 317875
Summary:
The NetBSD specific implementation of cxa_atexit() does not
preserve the 2nd argument if dso is equal to NULL.
Changes:
- Split paths of handling intercepted __cxa_atexit() and atexit(3).
This affects all supported Operating Systems.
- Add a local stack-like structure to hold the __cxa_atexit() context.
atexit(3) is documented in the C standard as calling callback from the
earliest to the oldest entry. This path also fixes potential ABI
problem of passing an argument to a function from the atexit(3)
callback mechanism.
- Add new test to ensure LIFO style of atexit(3) callbacks: atexit3.cc
Proposal to change the behavior of __cxa_atexit() in NetBSD has been rejected.
With the above changes TSan/NetBSD with the current tsan_interceptors.cc
can bootstrap into operation.
Sponsored by <The NetBSD Foundation>
Reviewers: vitalybuka, dvyukov, joerg, kcc, eugenis
Reviewed By: dvyukov
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D39619
llvm-svn: 317735
Summary:
The split in D39461 introduced separate C++ flags, but `cxx_flags` needs `-lrt` as well for the standalone build.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39497
llvm-svn: 317103
Summary:
Initially, Scudo had a monolithic design where both C and C++ functions were
living in the same library. This was not necessarily ideal, and with the work
on -fsanitize=scudo, it became more apparent that this needed to change.
We are splitting the new/delete interceptor in their own C++ library. This
allows more flexibility, notably with regard to std::bad_alloc when the work is
done. This also allows us to not link new & delete when using pure C.
Additionally, we add the UBSan runtimes with Scudo, in order to be able to have
a -fsanitize=scudo,undefined in Clang (see work in D39334).
The changes in this patch:
- split the cxx specific code in the scudo cmake file into a new library;
(remove the spurious foreach loop, that was not necessary)
- add the UBSan runtimes (both C and C++);
- change the test cmake file to allow for specific C & C++ tests;
- make C tests pure C, rename their extension accordingly.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D39461
llvm-svn: 317097
Fails on darwin
Revert "[fuzzer] Script to detect unbalanced allocation in -trace_malloc output"
Needs previous one.
This reverts commit r317034, r317036.
llvm-svn: 317061
Kuba Mracek