The !associated metadata may be attached to a global object declaration
with a single argument that references another global object. This
metadata prevents discarding of the global object in linker GC unless
the referenced object is also discarded.
Furthermore, when a function symbol is discarded by the linker, setting
up !associated metadata allows linker to discard counters, data and
values associated with that function symbol. This is not possible today
because there's metadata to guide the linker. This approach is also used
by other instrumentations like sanitizers.
Note that !associated metadata is only supported by ELF, it does not have
any effect on non-ELF targets.
Differential Revision: https://reviews.llvm.org/D76802
The !associated metadata may be attached to a global object declaration
with a single argument that references another global object. This
metadata prevents discarding of the global object in linker GC unless
the referenced object is also discarded.
Furthermore, when a function symbol is discarded by the linker, setting
up !associated metadata allows linker to discard counters, data and
values associated with that function symbol. This is not possible today
because there's metadata to guide the linker. This approach is also used
by other instrumentations like sanitizers.
Note that !associated metadata is only supported by ELF, it does not have
any effect on non-ELF targets.
Differential Revision: https://reviews.llvm.org/D76802
This flag suppresses TSan FPs on Darwin. I removed this flag
prematurely and have been dealing with the fallout ever since.
This commit puts back the flag, reverting 7d1085cb [1].
[1] https://reviews.llvm.org/D55075
It seems that after dc52ce424b, all big-endian problems have been fixed.
01899bb4e4 seems to have fixed XFAIL: * of
profile/instrprof-gcov-__gcov_flush-terminate.test
This essentially reverts commit 5a9b792d72 and
93d5ae3af1.
global-ctor.ll no longer checks what it intended to check
(@_GLOBAL__sub_I_global-ctor.ll needs a !dbg to work).
Rewrite it.
gcov 3.4 and gcov 4.2 use the same format, thus we can lower the version
requirement to 3.4
Summary: Non-zero malloc fill is causing way too many hard to debug issues.
Reviewers: kcc, pcc, hctim
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D81284
Summary:
As explained in https://bugs.llvm.org/show_bug.cgi?id=46208,
symbolization on Windows after inlining and around
lambdas/std::functions doesn't work very well. Under the new pass
manager, there is inlining at -O1.
use-after-scope-capture.cpp checks that the symbolization points to the
line containing "return x;", but the combination of
Windows/inlining/lambdas makes the symbolization point to the line
"f = [&x]() {".
Mark the lambda as noinline since this test is not a test for
symbolization.
Reviewers: hans, dblaikie, vitalybuka
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D81193
Use a struct to represent numerical versions instead of encoding release
names in an enumeration. This avoids the need to extend the enumeration
every time there is a new release.
Rename `GetMacosVersion() -> GetMacosAlignedVersion()` to better reflect
how this is used on non-MacOS platforms.
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D79970
Provides an assembly implementation of muldi3 for RISC-V, to solve bug 43388.
Since the implementation is the same as for mulsi3, that code was moved to
`riscv/int_mul_impl.inc` and is now reused by both `mulsi3.S` and `muldi3.S`.
Differential Revision: https://reviews.llvm.org/D80465
Remove it from target-specific scope which corresponds
to sanitizer_linux.cpp where it lives in the same macro
scope.
Differential Revision: https://reviews.llvm.org/D80864
This applies the learnings from [1]. What I intended as a simple
cleanup made me realize that the compiler-rt version checks have two
separate issues:
1) In some places (e.g., mmap flag setting) what matters is the kernel
version, not the OS version.
2) OS version checks are implemented by querying the kernel version.
This is not necessarily correct inside the simulators if the
simulator runtime isn't aligned with the host macOS.
This commit tackles 1) by adopting a separate query function for the
Darwin kernel version. 2) (and cleanups) will be dealt with in
follow-ups.
[1] https://reviews.llvm.org/D78942
rdar://63031937
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D79965
Summary:
This patch moves the setting of `LD_PRELOAD` "inwards" to avoid issues
where the built library needs to be loaded with the dynamic linker that
was configured with the build (and cannot, for example, be loaded by the
dynamic linker associated with the `env` utility).
Reviewed By: vitalybuka, nemanjai, jsji
Differential Revision: https://reviews.llvm.org/D79695
The test read from an uninitialized buffer which could cause the output
to be unpredictable.
The test is currently disabled so this won't actually change anything
until the test is re-enabled.
Summary:
The description of the fuzzer merge control file appears to be incorrect/out of date.
No "DONE" line appears in the control file. Rather, FT and COV are the markers that appear
following the STARTED line.
Reviewers: metzman, kcc
Reviewed By: kcc
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D80788
AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.LongJmpTest
AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.SigLongJmpTest
AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.LongJmpTest
AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.SigLongJmpTest
These failures will be examined properly when time permits.
rdar://problem/62141412
Add ThreadClock:: global_acquire_ which is the last time another thread
has done a global acquire of this thread's clock.
It helps to avoid problem described in:
https://github.com/golang/go/issues/39186
See test/tsan/java_finalizer2.cpp for a regression test.
Note the failuire is _extremely_ hard to hit, so if you are trying
to reproduce it, you may want to run something like:
$ go get golang.org/x/tools/cmd/stress
$ stress -p=64 ./a.out
The crux of the problem is roughly as follows.
A number of O(1) optimizations in the clocks algorithm assume proper
transitive cumulative propagation of clock values. The AcquireGlobal
operation may produce an inconsistent non-linearazable view of
thread clocks. Namely, it may acquire a later value from a thread
with a higher ID, but fail to acquire an earlier value from a thread
with a lower ID. If a thread that executed AcquireGlobal then releases
to a sync clock, it will spoil the sync clock with the inconsistent
values. If another thread later releases to the sync clock, the optimized
algorithm may break.
The exact sequence of events that leads to the failure.
- thread 1 executes AcquireGlobal
- thread 1 acquires value 1 for thread 2
- thread 2 increments clock to 2
- thread 2 releases to sync object 1
- thread 3 at time 1
- thread 3 acquires from sync object 1
- thread 1 acquires value 1 for thread 3
- thread 1 releases to sync object 2
- sync object 2 clock has 1 for thread 2 and 1 for thread 3
- thread 3 releases to sync object 2
- thread 3 sees value 1 in the clock for itself
and decides that it has already released to the clock
and did not acquire anything from other threads after that
(the last_acquire_ check in release operation)
- thread 3 does not update the value for thread 2 in the clock from 1 to 2
- thread 4 acquires from sync object 2
- thread 4 detects a false race with thread 2
as it should have been synchronized with thread 2 up to time 2,
but because of the broken clock it is now synchronized only up to time 1
The global_acquire_ value helps to prevent this scenario.
Namely, thread 3 will not trust any own clock values up to global_acquire_
for the purposes of the last_acquire_ optimization.
Reviewed-in: https://reviews.llvm.org/D80474
Reported-by: nvanbenschoten (Nathan VanBenschoten)
Some testcases are unexpectedly passing with NPM.
This is because the target functions are inlined in NPM.
I think we should add noinline attribute to keep these test points.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D79648
Summary:
This patch implements dynamic stack allocation for the VE target. Changes:
* compiler-rt: `__ve_grow_stack` to request stack allocation on the VE.
* VE: base pointer support, dynamic stack allocation.
Differential Revision: https://reviews.llvm.org/D79084
A few testcases are still using deprecated options.
warning: argument '-fsanitize-coverage=[func|bb|edge]' is deprecated,
use '-fsanitize-coverage=[func|bb|edge],[trace-pc-guard|trace-pc]'
instead [-Wdeprecated]
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D79741
This adds the family/model returned by CPUID for some Intel
Comet Lake CPUs. Instruction set and tuning wise these are
the same as "skylake".
These are not in the Intel SDM yet, but these should be correct.
Per target runtime dir may change the suffix of shared libs.
We can not assume we are always building with per_target_runtime_dir on.
Reviewed By: cryptoad
Differential Revision: https://reviews.llvm.org/D80243
Summary:
The previous code tries to strip out parentheses and anything in between
them. I'm guessing the idea here was to try to drop any listed arguments
for the function being symbolized. Unfortunately this approach is broken
in several ways.
* Templated functions may contain parentheses. The existing approach
messes up these names.
* In C++ argument types are part of a function's signature for the
purposes of overloading so removing them could be confusing.
Fix this simply by not trying to adjust the function name that comes
from `atos`.
A test case is included.
Without the change the test case produced output like:
```
WRITE of size 4 at 0x6060000001a0 thread T0
#0 0x10b96614d in IntWrapper<void >::operator=> const&) asan-symbolize-templated-cxx.cpp:10
#1 0x10b960b0e in void writeToA<IntWrapper<void > >>) asan-symbolize-templated-cxx.cpp:30
#2 0x10b96bf27 in decltype>)>> >)) std::__1::__invoke<void >), IntWrapper<void > >>), IntWrapper<void >&&) type_traits:4425
#3 0x10b96bdc1 in void std::__1::__invoke_void_return_wrapper<void>::__call<void >), IntWrapper<void > >>), IntWrapper<void >&&) __functional_base:348
#4 0x10b96bd71 in std::__1::__function::__alloc_func<void >), std::__1::allocator<void >)>, void >)>::operator>&&) functional:1533
#5 0x10b9684e2 in std::__1::__function::__func<void >), std::__1::allocator<void >)>, void >)>::operator>&&) functional:1707
#6 0x10b96cd7b in std::__1::__function::__value_func<void >)>::operator>&&) const functional:1860
#7 0x10b96cc17 in std::__1::function<void >)>::operator>) const functional:2419
#8 0x10b960ca6 in Foo<void >), IntWrapper<void > >::doCall>) asan-symbolize-templated-cxx.cpp:44
#9 0x10b96088b in main asan-symbolize-templated-cxx.cpp:54
#10 0x7fff6ffdfcc8 in start (in libdyld.dylib) + 0
```
Note how the symbol names for the frames are messed up (e.g. #8, #1).
With the patch the output looks like:
```
WRITE of size 4 at 0x6060000001a0 thread T0
#0 0x10005214d in IntWrapper<void (int)>::operator=(IntWrapper<void (int)> const&) asan-symbolize-templated-cxx.cpp:10
#1 0x10004cb0e in void writeToA<IntWrapper<void (int)> >(IntWrapper<void (int)>) asan-symbolize-templated-cxx.cpp:30
#2 0x100057f27 in decltype(std::__1::forward<void (*&)(IntWrapper<void (int)>)>(fp)(std::__1::forward<IntWrapper<void (int)> >(fp0))) std::__1::__invoke<void (*&)(IntWrapper<void (int)>), IntWrapper<void (int)> >(void (*&)(IntWrapper<void (int)>), IntWrapper<void (int)>&&) type_traits:4425
#3 0x100057dc1 in void std::__1::__invoke_void_return_wrapper<void>::__call<void (*&)(IntWrapper<void (int)>), IntWrapper<void (int)> >(void (*&)(IntWrapper<void (int)>), IntWrapper<void (int)>&&) __functional_base:348
#4 0x100057d71 in std::__1::__function::__alloc_func<void (*)(IntWrapper<void (int)>), std::__1::allocator<void (*)(IntWrapper<void (int)>)>, void (IntWrapper<void (int)>)>::operator()(IntWrapper<void (int)>&&) functional:1533
#5 0x1000544e2 in std::__1::__function::__func<void (*)(IntWrapper<void (int)>), std::__1::allocator<void (*)(IntWrapper<void (int)>)>, void (IntWrapper<void (int)>)>::operator()(IntWrapper<void (int)>&&) functional:1707
#6 0x100058d7b in std::__1::__function::__value_func<void (IntWrapper<void (int)>)>::operator()(IntWrapper<void (int)>&&) const functional:1860
#7 0x100058c17 in std::__1::function<void (IntWrapper<void (int)>)>::operator()(IntWrapper<void (int)>) const functional:2419
#8 0x10004cca6 in Foo<void (IntWrapper<void (int)>), IntWrapper<void (int)> >::doCall(IntWrapper<void (int)>) asan-symbolize-templated-cxx.cpp:44
#9 0x10004c88b in main asan-symbolize-templated-cxx.cpp:54
#10 0x7fff6ffdfcc8 in start (in libdyld.dylib) + 0
```
rdar://problem/58887175
Reviewers: kubamracek, yln
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79597
Summary:
This is collaboration between Marcel Boehme @ Monash, Australia and Valentin Manès plus Sang Kil Cha @ KAIST, South Korea.
We have made a few modifications to boost LibFuzzer performance by changing how weights are assigned to the seeds in the corpus. Essentially, seeds that reveal more "information" about globally rare features are assigned a higher weight. Our results on the Fuzzer Test Suite seem quite promising. In terms of bug finding, our Entropic patch usually finds the same errors much faster and in more runs. In terms of coverage, our version Entropic achieves the same coverage in less than half the time for the majority of subjects. For the lack of space, we shared more detailed performance results directly with @kcc. We'll publish the preprint with all the technical details as soon as it is accepted. Happy to share if you drop us an email.
There should be plenty of opportunities to optimise further. For instance, while Entropic achieves the same coverage in less than half the time, Entropic has a much lower #execs per second. We ran the perf-tool and found a few performance bottlenecks.
Thanks for open-sourcing LibFuzzer (and the entire LLVM Compiler Infrastructure)! This has been such a tremendous help to my research.
Patch By: Marcel Boehme
Reviewers: kcc, metzman, morehouse, Dor1s, vitalybuka
Reviewed By: kcc
Subscribers: dgg5503, Valentin, llvm-commits, kcc
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73776
When build in runtime bulid mode with LLVM_ENABLE_RUNTIMES,
the base-config-ix.cmake will complain about two errors.
One is empty string in replace, the other one is unknown `TEST_BIG_ENDIAN ` command.
This patch fix it so that we can test runtime build.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D80040
Petr Hosek