Extend the existing single-pass algorithm for `Merger::Merge` with an algorithm that gives better results. This new implementation can be used with a new **set_cover_merge=1** flag.
This greedy set cover implementation gives a substantially smaller final corpus (40%-80% less testcases) while preserving the same features/coverage. At the same time, the execution time penalty is not that significant (+50% for ~1M corpus files and far less for smaller corpora). These results were obtained by comparing several targets with varying size corpora.
Change `Merger::CrashResistantMergeInternalStep` to collect all features from each file and not just unique ones. This is needed for the set cover algorithm to work correctly. The implementation of the algorithm in `Merger::SetCoverMerge` uses a bitvector to store features that are covered by a file while performing the pass. Collisions while indexing the bitvector are ignored similarly to the fuzzer.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D105284
We've been seeing this test return 31 instead of 32 for the "functions"
line in this test on our AArch64 bots.
One possible cause is some of the children not finishing in time
before the llvm-profdata commands are run, if the machine is heavily loaded.
Wait for all the children to finish before exiting the parent.
Reviewed By: zequanwu
Differential Revision: https://reviews.llvm.org/D109222
This is important as with exceptions enabled, non-POD allocas often have
two lifetime ends: the exception handler, and the normal one.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D108365
The Solaris buildbots have been broken for some time:
In file included from /opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/compiler-rt/lib/asan/asan_interceptors.cpp:174:
/opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:4000:19: error: use of undeclared identifier 'wordexp_wrde_dooffs'
((flags & wordexp_wrde_dooffs) ? p->we_offs : 0) + p->we_wordc;
^
This was caused by D108646 <https://reviews.llvm.org/D108646>; the fix is
equivalent to D108838 <https://reviews.llvm.org/D108838>.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D109193
Similar to D97585.
D25456 used `S_ATTR_LIVE_SUPPORT` to ensure the data variable will be retained
or discarded as a unit with the counter variable, so llvm.compiler.used is
sufficient. It allows ld to dead strip unneeded profc and profd variables.
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D105445
[ubsan] warn inside the sigaction interceptor if static linking is suspected, and continue instead of crashing on null deref
Reviewed By: kostik
Differential Revision: https://reviews.llvm.org/D109081
Newer Xcode toolchains ship a new otool implementation that prints out
section contents in a slightly different way than otool-classic. Specify
"-V" to otool to get the expected test output.
Differential Revision: https://reviews.llvm.org/D108929
ASan, LSan, MSan and UBSan all allow to use environment variable `*SAN_SYMBOLIZER_PATH` to pass the symbolizer path, this patch add `TSAN_SYMBOLIZER_PATH` to TSan.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108911
In reviews.llvm.org/D108316 I missed a few instances of REAL(strlen) and
this change fixes that, as well as restoring one that seems like it
shouldn't have been changed.
Reviewed By: hctim, vitalybuka
Differential Revision: https://reviews.llvm.org/D108843
In this mode libc++ headers end up in two directories:
* include/<triple>/c++/v1 for the site config header
* include/c++/v1 for everything else
Also switch from -I to -isystem.
Differential Revision: https://reviews.llvm.org/D108841
Replace D107203, because __llvm_profile_set_file_object is usually used when the
process doesn't have permission to open/create file. That patch trying to copy
from old profile to new profile contradicts with the usage.
Differential Revision: https://reviews.llvm.org/D108242
qsort can reuse qsort_r if available.
bsearch always passes key as the first comparator argument, so we
can use it to wrap the original comparator.
Differential Revision: https://reviews.llvm.org/D108751
We have to avoid calling renameat2 and clone on FreeBSD.
Additionally, the mcontext structure has different members.
Reviewed By: jrtc27, luismarques
Differential Revision: https://reviews.llvm.org/D103886
Breaks realpath(, nullptr) for all sanitizers.
Somehow INTERCEPT_FUNCTION and INTERCEPT_FUNCTION_VER return
false even if everything seemingly right.
And this is the issue for COMMON_INTERCEPT_FUNCTION_GLIBC_VER_MIN.
There is a check in every sanitlizer:
if (!INTERCEPT_FUNCTION_VER(name, ver) && !INTERCEPT_FUNCTION(name))
For non-versioned interceptors when INTERCEPT_FUNCTION returns false
it's not considered fatal, and it just prints a warning.
However INTERCEPT_FUNCTION_VER in this case will fallback to
INTERCEPT_FUNCTION replacing realpath with wrong version.
We need to investigate that before relanding the patch.
This reverts commit faef0d042f.
In that case it is very likely that there will be a tag mismatch anyway.
We handle the case that the pointer belongs to neither of the allocators
by getting a nullptr from allocator.GetBlockBegin.
Reviewed By: hctim, eugenis
Differential Revision: https://reviews.llvm.org/D108383
Handle the case of wordexp being invoked with WRDE_DOOFFS and
we.we_offs set to a positive value, which will result in NULL
entries prepended to the result. With this change the entire
result, containing both NULL and actual entries, is unpoisoned.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108646
* c_api_tests was failing to build after the API change to
__orc_rt_CWrapperFunctionResultAllocate
* wrapper_function_utils_test was causing an assertion failure, because
it was creating a result for `void(void)` with Size = 0, but seeing an
uninitialized pointer, which it considered to be an out-of-bound
error.
I noticed locally that making modifications to c_api.h is not causing
these unit tests to be rebuilt, which may be how the bug slipped in in
the first place.
Differential Revision: https://reviews.llvm.org/D108649
Fixes a regression when the allocator is disabled, and a dirty
allocation is re-used. This only occurs when the allocator is disabled,
so a test-only fix, but still necessary.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D108650
Set SA_SIGINFO only if we set sighandler, or we can set the flag, and
return it as 'old' without actual sigaction set.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D108616
* Cannot use sizeof() on another union member
* nullptr vs NULL
* () vs (void)
Incidentally, fix an incorrect comment about memory ownership on the
argument to __orc_rt_CreateCWrapperFunctionResultFromOutOfBandError,
which is copied, not moved.
llvm-libc is expected to be built with sanitizers and not use interceptors in
the long run. For now though, we have a hybrid process, where functions
implemented in llvm-libc are instrumented, and glibc fills and sanitizer
interceptors fill in the rest.
Current sanitizers have an invariant that the REAL(...) function called from
inside of an interceptor is uninstrumented. A lot of interceptors call strlen()
in order to figure out the size of the region to check/poison. Switch these
callsites over to the internal, unsanitized implementation.
Reviewed By: hctim, vitalybuka
Differential Revision: https://reviews.llvm.org/D108316
WrapperFunctionResult no longer supports wrapping constant data, so this patch
provides direct non-const access to the wrapped data. Since wrapped data can now
be written, the WrapperFunctionResult::allocate method can be simplified to
return a WrapperFunctionResult.
This is essentially the same change (and with the same motivation) as LLVM
commit 8b117830b1, but applied to the ORC runtime's WrapperFunctionResult code.
In the raw profile, binary ids immediately follow the header so when
computing counters offset we need to account for the new section.
Differential Revision: https://reviews.llvm.org/D108608