Extract ParseVersion helper function for testing.

Reviewed By: delcypher

Differential Revision: https://reviews.llvm.org/D80761

Fixup for ba6b1b43.

Fixup for ba6b1b43.

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

add debug code to chase down a rare crash in asan/lsan https://github.com/google/sanitizers/issues/1193

Summary: add debug code to chase down a rare crash in asan/lsan https://github.com/google/sanitizers/issues/1193

Reviewers: vitalybuka

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D80967

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

Use internal_memcpy instead.

Differential Revision: https://reviews.llvm.org/D80732

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

Summary:
See https://github.com/google/sanitizers/issues/1253.

Small patch to enable compilation on (ancient) Red Hat Enterprise Linux 5.

Reviewers: kcc, vitalybuka

Reviewed By: vitalybuka

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D80648

pthread_cond_wait needs a loop around it to handle spurious wake ups,
as well as the case when signal runs before wait.

  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)

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

Summary:
Fixes this build error with GCC 9.3.0:

```
../lib/fuzzer/afl/afl_driver.cpp:114:30: error: expected unqualified-id before string constant
  114 | __attribute__((weak)) extern "C" void __sanitizer_set_report_fd(void *);
      |                              ^~~
```

Reviewers: metzman, kcc

Reviewed By: kcc

Subscribers: #sanitizers

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D80479

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.

The oldest supported deployment target currently is 10.7 [1].  We can
remove a few outdated checks.

[1] https://github.com/llvm/llvm-project/blob/3db893b3712a5cc98ac0dbc88e08df70069be216/compiler-rt/cmake/config-ix.cmake#L397

Reviewed By: delcypher

Differential Revision: https://reviews.llvm.org/D79958

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

These statistics are intended to help us tune the scudo MTE
implementation.

Differential Revision: https://reviews.llvm.org/D79913

In a previous change I added a shim for fork(), but when compiled from InstrProfiling.c, the
required header file was not included, so pid_t was undefined. This change adds that include.

Reviewers: probinson

Subscribers: #sanitizers llvm-commits

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D79839

Summary:
Synchronize the function definition with the LLVM documentation.

https://llvm.org/docs/Atomics.html#libcalls-atomic

GCC also returns bool for the same atomic builtin.

Reviewers: theraven

Reviewed By: theraven

Subscribers: theraven, dberris, jfb, #sanitizers

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D79845

Fixes PR45673

The commit 9180c14f (D76206) resolved only a part of the problem
of concurrent .gcda file creation. It ensured that only one process
creates the file but did not ensure that the process locks the
file first. If not, the process which created the file may clobber
the contents written by a process which locked the file first.
This is the cause of PR45673.

This commit prevents the clobbering by revising the assumption
that a process which creates the file locks the file first.
Regardless of file creation, a process which locked the file first
uses fwrite (new_file==1) and other processes use mmap (new_file==0).

I also tried to keep the creation/first-lock process same by using
mkstemp/link/unlink but the code gets long. This commit is more
simple.

Note: You may be confused with other changes which try to resolve
concurrent file access. My understanding is (may not be correct):

D76206:   Resolve race of .gcda file creation (but not lock)
This one: Resolve race of .gcda file creation and lock
D54599:   Same as D76206 but abandoned?
D70910:   Resolve race of multi-threaded counter flushing
D74953:   Resolve counter sharing between parent/children processes
D78477:   Revision of D74953

Differential Revision: https://reviews.llvm.org/D79556

In a big-endian .gcda file, the first four bytes are "gcda" instead of "adcg".
All 32-bit values are in big-endian.

With this change, libclang_rt.profile can hopefully produce gcov
compatible output.

D49132 is partially correct. For 64-bit values, the lower 32-bit part comes
before the higher 32-bit part (in a little-endian manner).

For 32-bit values, libgcov reads/writes 32-bit values in native endianness.

[gcov] Emit GCOV_TAG_OBJECT_SUMMARY/GCOV_TAG_PROGRAM_SUMMARY correctly and fix llvm-cov's decoding of runcount

gcov 9 (r264462) started to use GCOV_TAG_OBJECT_SUMMARY. Before,
GCOV_TAG_PROGRAM_SUMMARY was used.
libclang_rt.profile should emit just one tag according to the version.

Another bug introduced by rL194499 is that the wrong runcount field was
selected.

Fix the two bugs so that gcov can correctly decode "Runs:" from
libclang_rt.profile produced .gcda files, and llvm-cov gcov can
correctly decode "Runs:" from libgcov produced .gcda files.

Summary:
Fix hwasan allocator not respecting the requested alignment when it is
higher than a page, but still within primary (i.e. [2048, 65536]).

Reviewers: pcc, hctim, cryptoad

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D79656

Create a sanitizer_ptrauth.h header that #includes <ptrauth> when
available and defines just the required macros as "no ops" otherwise.
This should avoid the need for excessive #ifdef'ing.

Follow-up to and discussed in: https://reviews.llvm.org/D79132

Reviewed By: delcypher

Differential Revision: https://reviews.llvm.org/D79540

Summary:
The Hygon Dhyana processor supports hardware CRC32.

Related link:
https://reviews.llvm.org/D78874

Result of "make check":
Testing Time: 1364.04s
  Unsupported Tests:   317
  Expected Passes  : 36802
  Expected Failures:   161
[100%] Built target check-llvm
[100%] Built target check

Reviewers: cryptoad

Reviewed By: cryptoad

Subscribers: craig.topper, cryptoad, cfe-commits, #sanitizers, llvm-commits

Tags: #clang, #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D62368

Defaulting to -Xclang -coverage-version='407*' makes .gcno/.gcda
compatible with gcov [4.7,8)

In addition, delete clang::CodeGenOptionsBase::CoverageExtraChecksum and GCOVOptions::UseCfgChecksum.
We can infer the information from the version.

With this change, .gcda files produced by `clang --coverage a.o` linked executable can be read by gcov 4.7~7.
We don't need other -Xclang -coverage* options.
There may be a mismatching version warning, though.

(Note, GCC r173147 "split checksum into cfg checksum and line checksum"
 made gcov 4.7 incompatible with previous versions.)

rL144865 incorrectly wrote function names for GCOV_TAG_FUNCTION
(this might be part of the reasons the header says
"We emit files in a corrupt version of GCOV's "gcda" file format").

rL176173 and rL177475 realized the problem and introduced -coverage-no-function-names-in-data
to work around the issue. (However, the description is wrong.
libgcov never writes function names, even before GCC 4.2).

In reality, the linker command line has to look like:

clang --coverage -Xclang -coverage-version='407*' -Xclang -coverage-cfg-checksum -Xclang -coverage-no-function-names-in-data

Failing to pass -coverage-no-function-names-in-data can make gcov 4.7~7
either produce wrong results (for one gcov-4.9 program, I see "No executable lines")
or segfault (gcov-7).
(gcov-8 uses an incompatible format.)

This patch deletes -coverage-no-function-names-in-data and the related
function names support from libclang_rt.profile

Required on X86 because no TBI.

Summary:
This is necessary to handle calls to free() after __hwasan_thread_exit,
which is possible in glibc.

Also, add a null check to GetCurrentThread, otherwise the logic in
GetThreadByBufferAddress turns it into a non-null value. This means that
all of the checks for GetCurrentThread() != nullptr do not have any
effect at all right now!

Reviewers: pcc, hctim

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D79608