Checking the OS version via `GetMacosAlignedVersion()` now works in
simulators [1].  Let's use it to simplify `DyldNeedsEnvVariable()`.

[1] 3fb0de82

Reviewed By: delcypher

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

compiler-rt checks OS versions by querying the Darwin kernel version.
This is not necessarily correct inside the simulators if the simulator
runtime is not aligned with the host macOS.  Let's instead check the
`SIMULATOR_RUNTIME_VERSION` env var.

rdar://63031937

Reviewed By: delcypher

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

Neither the Illumos `ld` nor the Solaris 11.3 one support the `--version-script` and
`z gnu-linker-script-compat` options, which breaks the `compiler-rt` build.

This patch checks for both options instead of hardcoding their use.

Tested on `amd-pc-solaris2.11` (all of Solaris 11.4, 11.3, and Illumos).

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

make_unique is a C++14 feature, and this prevents us from building on
Ubuntu Trusty. While we do use a C++14 compatible toolchain for building
in general, we fall back to the system toolchain for building the
compiler-rt tests.

The reason is that those tests get cross-compiled for e.g. 32-bit and
64-bit x86, and while the toolchain provides libstdc++ in those
flavours, the resulting compiler-rt test binaries don't get RPATH set
and so won't start if they're linked with that toolchain.

We've tried linking the test binaries against libstdc++ statically, by
passing COMPILER_RT_TEST_COMPILER_CFLAGS=-static-libstdc++. That mostly
works, but some test targets append -lstdc++ to the compiler invocation.

So, after spending way too much time on this, let's just avoid C++14
here for now.

This adds a new extern "C" function that serves the same purpose. This removes the need for external users to depend on internal headers in order to use this feature. It also standardizes the interface in a way that other fuzzing engines will be able to match.

Patch By: IanPudney

Reviewed By: kcc

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

Summary:
Fix up a slight bug with the crash handler API, where we say that we
return the size of the collected trace (instead of the size of the trace
that's returned) when the return buffer is too small, and the result is
truncated.

Also, as a result, patch up a small uninitialized memory bug.

Reviewers: morehouse, eugenis

Reviewed By: eugenis

Subscribers: #sanitizers

Tags: #sanitizers

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

Fix up a small bug where we used a partially-uninitialized sigaction
struct in the optional signal handler. Shouldn't be a user-visible
change.

We added -nostdinc++ to clang_rt.profile in https://reviews.llvm.org/D84205.
This will cause warnings when building with LLVM_ENABLE_LIBCXX,
and failure if with Werror on.

This patch is to fix it by removing unused -stdlib,
similar to what we have done in https://reviews.llvm.org/D42238.

Reviewed By: phosek

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

Summary:
On 32-b, the release algo loops multiple times over the freelist for a size
class, which lead to a decrease in performance when there were a lot of free
blocks.

This changes the release functions to loop only once over the freelist, at the
cost of using a little bit more memory for the release process: instead of
working on one region at a time, we pass the whole memory area covered by all
the regions for a given size class, and work on sub-areas of `RegionSize` in
this large area. For 64-b, we just have 1 sub-area encompassing the whole
region. Of course, not all the sub-areas within that large memory area will
belong to the class id we are working on, but those will just be left untouched
(which will not add to the RSS during the release process).

Reviewers: pcc, cferris, hctim, eugenis

Subscribers: llvm-commits, #sanitizers

Tags: #sanitizers

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

If we define memcmp in an archive, bcmp should be defined as well (many libc
define bcmp/memcmp in one object file).  Otherwise if the application calls bcmp
or strcmp which gets optimized to bcmp (SimplifyLibCalls), the undefined
reference may pull in an optimized bcmp/strcmp implementation (libc replacement)
later on the linker command line.  If both libFuzzer's memcmp and the optimized
memcmp are strong => there will be a multiple definition error.

This reverts commit 22a376e7.

Summary: FuzzerInterceptors.cpp includes <sanitizer/common_interface_defs.h>, and this patch adds a missing include_directories to make sure the included file is found.

Reviewers: morehouse, hctim, dmajor

Subscribers: mgorny, #sanitizers

Tags: #sanitizers

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

This guarantees that we will detect a buffer overflow or underflow
that overwrites an adjacent block. This spatial guarantee is similar
to the temporal guarantee that we provide for immediate use-after-free.

Enabling odd/even tags involves a tradeoff between use-after-free
detection and buffer overflow detection. Odd/even tags make it more
likely for buffer overflows to be detected by increasing the size of
the guaranteed "red zone" around the allocation, but on the other
hand use-after-free is less likely to be detected because the tag
space for any particular chunk is cut in half. Therefore we introduce
a tuning setting to control whether odd/even tags are enabled.

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

Support fast16labels in `dfsan_has_label`, and print an error for all
other API functions.  For `dfsan_dump_labels` we return silently rather
than crashing since it is also called from the atexit handler where it
is undefined behavior to call exit() again.

Reviewed By: kcc

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

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

Summary:
Allows other-language libFuzzer derivatives to invoke the driver.

Patch By: Ian Eldred Pudney <ipudney@google.com>

Reviewers: morehouse, kcc

Reviewed By: morehouse

Subscribers: #sanitizers

Tags: #sanitizers

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

This reverts commit 19d9c039 due to
buildbot failure.

Recommit "[libFuzzer] Link libFuzzer's own interceptors when other compiler runtimes are not linked."

Summary: libFuzzer intercepts certain library functions such as memcmp/strcmp by defining weak hooks. Weak hooks, however, are called only when other runtimes such as ASan is linked. This patch defines libFuzzer's own interceptors, which is linked into the libFuzzer executable when other runtimes are not linked, i.e., when -fsanitize=fuzzer is given, but not others.

The patch once landed but was reverted in 8ef9e2bf due to an assertion failure caused by calling an intercepted function, strncmp, while initializing the interceptors in fuzzerInit(). This issue is now fixed by calling libFuzzer's own implementation of library functions (i.e., internal_*) when the fuzzer has not been initialized yet, instead of recursively calling fuzzerInit() again.

Reviewers: kcc, morehouse, hctim

Subscribers: #sanitizers, krytarowski, mgorny, cfe-commits

Tags: #clang, #sanitizers

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

A last-minute silent change in  D84046 <https://reviews.llvm.org/D84046> broke the Solaris buildbots (Solaris/sparcv9 <http://lab.llvm.org:8014/builders/clang-solaris11-sparcv9/builds/6772>, Solaris/amd64 <http://lab.llvm.org:8014/builders/clang-solaris11-amd64/builds/5434>):

  [2/3679] Building CXX object projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.sparc.dir/sanitizer_posix_libcdep.cpp.o
  FAILED: projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.sparc.dir/sanitizer_posix_libcdep.cpp.o
  /opt/llvm-buildbot/bin/c++  -DHAVE_RPC_XDR_H=1 -D_DEBUG -D_FILE_OFFSET_BITS=64 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/compiler-rt/lib/sanitizer_common -I/opt/llvm-buildbot/home/solaris11-sparcv9/clang-solaris11-sparcv9/llvm/compiler-rt/lib/sanitizer_common -Iinclude -I/opt/llvm-buildbot/home/solaris11-sparcv9/clang-solaris11-sparcv9/llvm/llvm/include -I/opt/llvm-buildbot/home/solaris11-sparcv9/clang-solaris11-sparcv9/llvm/llvm/include/llvm/Support/Solaris -I/opt/llvm-buildbot/home/solaris11-sparcv9/clang-solaris11-sparcv9/llvm/compiler-rt/lib/sanitizer_common/.. -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -std=c++14 -Wno-unused-parameter -O3     -m32 -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fvisibility=hidden -fno-lto -O3 -g -Wno-variadic-macros -Wno-non-virtual-dtor -fno-rtti -Wframe-larger-than=570 -UNDEBUG -std=c++14 -MD -MT projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.sparc.dir/sanitizer_posix_libcdep.cpp.o -MF projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.sparc.dir/sanitizer_posix_libcdep.cpp.o.d -o projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.sparc.dir/sanitizer_posix_libcdep.cpp.o -c /opt/llvm-buildbot/home/solaris11-sparcv9/clang-solaris11-sparcv9/llvm/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp
  /opt/llvm-buildbot/home/solaris11-sparcv9/clang-solaris11-sparcv9/llvm/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:50:16: error: conflicting declaration of C function ‘int madvise(caddr_t, std::size_t, int)’
   extern "C" int madvise(caddr_t, size_t, int);
                  ^~~~~~~
  In file included from /opt/llvm-buildbot/home/solaris11-sparcv9/clang-solaris11-sparcv9/llvm/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:32:0:
  /usr/include/sys/mman.h:232:12: note: previous declaration ‘int madvise(void*, std::size_t, int)’
   extern int madvise(void *, size_t, int);
              ^~~~~~~

This patch undoes that change.

Tested on `amd64-pc-solaris2.11` (Solaris 11.4 and OpenIndiana).

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

A malloc implementation may return a pointer to some allocated space.  It is
undefined for libclang_rt.profile- to access the object - which actually happens
in instrumentTargetValueImpl, where ValueCounters[CounterIndex] may access a
ValueProfNode (from another allocated object) and crashes when the code accesses
the object referenced by CurVNode->Next.

Summary:
Support fast16labels in `dfsan_has_label`, and print an error for all
other API functions.

Reviewers: kcc, vitalybuka, pcc

Reviewed By: kcc

Subscribers: jfb, llvm-commits, #sanitizers

Tags: #sanitizers

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

This reverts commit 4a539faf.

There is a __llvm_profile_instrument_range related crash in PGO-instrumented clang:

```
(gdb) bt
llvm::ConstantRange const&, llvm::APInt const&, unsigned int, bool) ()
llvm::ScalarEvolution::getRangeForAffineAR(llvm::SCEV const*, llvm::SCEV
const*, llvm::SCEV const*, unsigned int) ()
```

(The body of __llvm_profile_instrument_range is inlined, so we can only find__llvm_profile_instrument_target in the trace)

```
 23│    0x000055555dba0961 <+65>:    nopw   %cs:0x0(%rax,%rax,1)
 24│    0x000055555dba096b <+75>:    nopl   0x0(%rax,%rax,1)
 25│    0x000055555dba0970 <+80>:    mov    %rsi,%rbx
 26│    0x000055555dba0973 <+83>:    mov    0x8(%rsi),%rsi  # %rsi=-1 -> SIGSEGV
 27│    0x000055555dba0977 <+87>:    cmp    %r15,(%rbx)
 28│    0x000055555dba097a <+90>:    je     0x55555dba0a76 <__llvm_profile_instrument_target+342>
```

Summary: Came up in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1103108#c21

Reviewers: eugenis

Reviewed By: eugenis

Subscribers: #sanitizers

Tags: #sanitizers

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

This upgrade should be friction-less because we've already been ensuring
that CMake >= 3.13.4 is used.

This is part of the effort discussed on llvm-dev here:

  http://lists.llvm.org/pipermail/llvm-dev/2020-April/140578.html

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

For now, xdrrec_create is only intercepted Linux as its signature
is different on Solaris.

The method of intercepting xdrrec_create isn't super ideal but I
couldn't think of a way around it: Using an AddrHashMap combined
with wrapping the userdata field.

We can't just allocate a handle on the heap in xdrrec_create and leave
it at that, since there'd be no way to free it later. This is because it
doesn't seem to be possible to access handle from the XDR struct, which
is the only argument to xdr_destroy.
On the other hand, the callbacks don't have a way to get at the
x_private field of XDR, which is what I chose for the HashMap key. So we
need to wrap the handle parameter of the callbacks. But we can't just
pass x_private as handle (as it hasn't been set yet). We can't put the
wrapper struct into the HashMap and pass its pointer as handle, as the
key we need (x_private again) hasn't been set yet.

So I allocate the wrapper struct on the heap, pass its pointer as
handle, and put it into the HashMap so xdr_destroy can find it later and
destroy it.

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

- there are additional fields for glob_t struct, thus size check is failing.
- to access old mman.h api based on caddr_t, _XOPEN_SOURCE needs to be not defined
 thus we provide the prototype.
- prxmap_t constified.

Reviewers: ro, eugenis

Reviewed-By: ro

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

Summary:
It turns out the `CHECK(addr >= reinterpret_cast<upt>(info.dli_saddr)`
can fail because on armv7s on iOS 9.3 `dladdr()` returns
`info.dli_saddr` with an address larger than the address we provided.

We should avoid crashing here because crashing in the middle of reporting
an issue is very unhelpful. Instead we now try to compute a function offset
if the value we get back from `dladdr()` looks sane, otherwise we don't
set the function offset.

A test case is included. It's basically a slightly modified version of
the existing `test/sanitizer_common/TestCases/Darwin/symbolizer-function-offset-dladdr.cpp`
test case that doesn't run on iOS devices right now.

More details:

In the concrete scenario on armv7s `addr` is `0x2195c870` and the returned
`info.dli_saddr` is `0x2195c871`.

This what LLDB says when disassembling the code.

```
(lldb) dis -a 0x2195c870
libdyld.dylib`<redacted>:
    0x2195c870 <+0>: nop
    0x2195c872 <+2>: blx    0x2195c91c                ; symbol stub for: exit
    0x2195c876 <+6>: trap
```

The value returned by `dladdr()` doesn't make sense because it points
into the middle of a instruction.

There might also be other bugs lurking here because I noticed that the PCs we
gather during stackunwinding (before changing them with
`StackTrace::GetPreviousInstructionPc()`) look a little suspicious (e.g.  the
PC stored for the frame with fail to symbolicate is 0x2195c873) as they don't
look properly aligned. This probably warrants further investigation in the future.

rdar://problem/65621511

Reviewers: kubamracek, yln

Subscribers: kristof.beyls, llvm-commits, #sanitizers

Tags: #sanitizers

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

This CL allows asan allocator in fuchsia to decommit shadow memory
for memory allocated using mmap.

Big allocations in asan end up being allocated via `mmap` and freed with
`munmap`. However, when that memory is freed, asan returns the
corresponding shadow memory back to the OS via a call to
`ReleaseMemoryPagesToOs`.

In fuchsia, `ReleaseMemoryPagesToOs` is a no-op: to be able to free
memory back to the OS, you have to hold a handle to the vmo you want to
modify, which is tricky at the ReleaseMemoryPagesToOs level as that
function is not exclusively used for shadow memory.

The function `__sanitizer_fill_shadow` fills a given shadow memory range
with a specific value, and if that value is 0 (unpoison) and the memory
range is bigger than a threshold parameter, it will decommit that memory
if it is all zeroes.

This CL modifies the `FlushUnneededASanShadowMemory` function in
`asan_poisoning.cpp` to add a call to `__sanitizer_fill_shadow` with
value and threshold = 0. This way, all the unneeded shadow memory gets
returned back to the OS.

A test for this behavior can be found in fxrev.dev/391974

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

Change-Id: Id6dd85693e78a222f0329d5b2201e0da753e01c0

Note: Resubmission with frame pointers force-enabled to fix builds with
-DCOMPILER_RT_BUILD_BUILTINS=False

Summary:
Splits the unwinder into a non-segv (for allocation/deallocation traces) and a
segv unwinder. This ensures that implementations can select an accurate, slower
unwinder in the segv handler (if they choose to use the GWP-ASan provided one).
This is important as fast frame-pointer unwinders (like the sanitizer unwinder)
don't like unwinding through signal handlers.

Reviewers: morehouse, cryptoad

Reviewed By: morehouse, cryptoad

Subscribers: cryptoad, mgorny, eugenis, pcc, #sanitizers

Tags: #sanitizers

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

Most of the code in compiler_rt is C code. However, clang_rt.profile
contains the InstrProfilingRuntime.cpp file, which builds as C++. This
means that including e.g. <stdint.h> will actually include libc++'s
<stdint.h> and then #include_next the system's <stdint.h>. However, if
the target we're building compiler-rt for isn't supported by libc++,
this will lead to a failure since libc++'s <stdint.h> includes <__config>,
which performs various checks.

Since the goal seems to *not* be including any header from the C++ Standard
Library in clang_rt.profile, using -nostdinc++ to ensure that doesn't
happen unknowingly seems to make sense.

rdar://65852694

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

It was causing tests to fail in -DCOMPILER_RT_BUILD_BUILTINS=OFF builds:

   GwpAsan-Unittest :: ./GwpAsan-x86_64-Test/BacktraceGuardedPoolAllocator.DoubleFree
   GwpAsan-Unittest :: ./GwpAsan-x86_64-Test/BacktraceGuardedPoolAllocator.UseAfterFree

see comment on the code review.

> Summary:
> Splits the unwinder into a non-segv (for allocation/deallocation traces) and a
> segv unwinder. This ensures that implementations can select an accurate, slower
> unwinder in the segv handler (if they choose to use the GWP-ASan provided one).
> This is important as fast frame-pointer unwinders (like the sanitizer unwinder)
> don't like unwinding through signal handlers.
>
> Reviewers: morehouse, cryptoad
>
> Reviewed By: morehouse, cryptoad
>
> Subscribers: cryptoad, mgorny, eugenis, pcc, #sanitizers
>
> Tags: #sanitizers
>
> Differential Revision: https://reviews.llvm.org/D83994

This reverts commit 502f0cc0.

(facepalm)

GCC r187297 (2012-05) introduced `__gcov_dump` and `__gcov_reset`.
  `__gcov_flush = __gcov_dump + __gcov_reset`

The resolution to https://gcc.gnu.org/PR93623 ("No need to dump gcdas when forking" target GCC 11.0) removed the unuseful and undocumented __gcov_flush.

Close PR38064.

Reviewed By: calixte, serge-sans-paille

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

Also adds a sanitizers-wide test, and a msan test, for these functions.

The incorrect symbol will cause linking failures for 32-bit targets:

clang_rt.fuzzer-i386.lib(FuzzerDriver.obj) : error LNK2001: unresolved external symbol __libfuzzer_is_present

Verified no longer fails to link with this change for 32-bit and still succeeds for 64-bit MSVC.

Reviewed By: vitalybuka

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

This is needed because macOS on Apple Silicon has some reserved pages inside the "regular" shadow memory location, and mapping over that location fails.

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

Fix build failure in Fuchsia build from refactoring in
5d2be1a1

Guard the moved versions of ReserveShadowMemoryRange and ProtectGap
the same way they were in the asan code originally (not for Fuchsia or
RTEMS). Otherwise we end up with unsats as they invoke functions not
defined there.