Support macOS 11 in our runtime version checking code and update
`GetMacosAlignedVersionInternal()` accordingly.  This follows the
implementation of `Triple::getMacOSXVersion()` in the Clang driver.

Reviewed By: delcypher

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

This also allows intercepting these getprotoent functions on Linux as
well, since Linux exposes them.

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

This code should reside in the c-library.

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

This reverts commit f3a08950.

888951aa introduced a fix that
should make the disabled tests work again.

rdar://problem/62141412

Summary:
28c91219 introduced an interceptor for `sigaltstack`. It turns out this
broke `setjmp` on i386 macOS. This is because the implementation of `setjmp` on
i386 macOS is written in assembly and makes the assumption that the call to
`sigaltstack` does not clobber any registers.  Presumably that assumption was
made because it's a system call.  In particular `setjmp`  assumes that before
and after the call that `%ecx` will contain a pointer the `jmp_buf`. The
current interceptor breaks this assumption because it's written in C++ and
`%ecx` is not a callee-saved register. This could be fixed by writing a
trampoline interceptor to the existing interceptor in assembly that
ensures all the registers are preserved. However, this is a lot of work
for very little gain. Instead this patch just disables the interceptor
on i386 macOS.

For other Darwin architectures it currently appears to be safe to intercept
`sigaltstack` using the current implementation because:

* `setjmp` for x86_64 saves the pointer `jmp_buf` to the stack before calling `sigaltstack`.
* `setjmp` for armv7/arm64/arm64_32/arm64e appears to not call `sigaltstack` at all.

This patch should unbreak (once they are re-enabled) the following
tests:

```
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
AddressSanitizer-i386-darwin :: TestCases/longjmp.cpp
```

This patch introduces a `SANITIZER_I386` macro for convenience.

rdar://problem/62141412

Reviewers: kubamracek, yln, eugenis

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

Tags: #sanitizers

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

The Swift symbol name prefix has changed from `_T0` to `_$s` as
documented here [1].  This prevents Swift names from properly being
symbolicated when using the in-process LLVM symbolizer.  The best way to
fix this seems to be to avoid the duplication of "Is this a Swift symbol
name?" here.  We can simply remove this check as `swift_demangle`
already returns null for non-Swift names [2,3].

The check was included in the initial support for Swift name demangling
to avoid superfluous calls to `dlsym()` [4].  A subsequent commit
changed this logic to retrieve the `swift_demangle` function pointer
eagerly during sanitizer initialization, but did not remove the check
[5].

[1] https://github.com/apple/swift/blob/master/docs/ABI/Mangling.rst
[2] https://github.com/apple/swift/blob/b5a8b518eae54cea997f3b0954760fc7858829f6/include/swift/Demangling/Demangle.h#L643
[3] https://github.com/apple/swift/blob/b5a8b518eae54cea997f3b0954760fc7858829f6/stdlib/public/runtime/Demangle.cpp#L656
[4] https://reviews.llvm.org/D19135
[5] https://reviews.llvm.org/D20015

rdar://62753845

Reviewers: kubamracek, delcypher, dcoughlin, samsonov, thakis

Reviewed By: kubamracek

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

atexit registered functions run earlier so `__attribute__((destructor))`
annotated functions cannot be tracked.

Set a priority of 100 (compatible with GCC 7 onwards) to track
destructors and destructors whose priorities are greater than 100.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7970

Reviewed By: calixte, marco-c

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

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

macOS versions do not necessarily start with 10 anymore.  Remove an
obsolete assert.

This patch changes types of some integer function arguments or return values from `si_int` to the default `int` type to make it more compatible with `libgcc`.

The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on `int`, `float` and other such types being just illustrations in some cases while the actual types are expressed with machine modes.

Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations.

This patch is expected to not change behavior at all for targets with 32-bit `int` type.

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

Fix a mismatched #if/#endif comments from my previous commit.

Some parts of existing codebase assume the default `int` type to be (at least) 32 bit wide. On 16 bit targets such as MSP430 this may cause Undefined Behavior or results being defined but incorrect.

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

Summary: Allow compiler-rt to build for arm64 support on macOS.

Reviewers: arphaman, doug.gregor, dexonsmith

Reviewed By: arphaman, dexonsmith

Subscribers: dberris, mgorny, kristof.beyls, jkorous, ributzka, danielkiss, #sanitizers, llvm-commits

Tags: #sanitizers

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

There are two different _generic_ lists of source files in the compiler-rt/lib/builtins/CMakeLists.txt. Now there is no simple way to not use the tf-variants of helpers at all.

Since there exists a separate `GENERIC_TF_SOURCES` list, it seems quite natural to move all float128-related helpers there. If it is not possible for some reason, it would be useful to have an explanation of that reason somewhere near the `GENERIC_TF_SOURCES` definition.

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

This reverts commit 63a89693.

Due to a build failure like http://lab.llvm.org:8011/builders/sanitizer-windows/builds/65386/steps/annotate/logs/stdio

Extend the memop value profile buckets to be more flexible (could accommodate a
mix of individual values and ranges) and to cover more value ranges (from 11 to
22 buckets).

Disabled behind a flag (to be enabled separately) and the existing code to be
removed later.

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

Summary:
Currently, there is no way to let the `InternalSymbolizer` implemented
functions know if inline frames should be symbolized. This patch updates
the function `__sanitizer_symbolize_code` to include a parameter for
this ASAN option and toggle between LLVM symbolization functions when
appropriate.

Fixes the following two failing tests when internal symbolization is
enabled:
```
SanitizerCommon-*-x86_64-Linux :: print-stack-trace.cpp
SanitizerCommon-*-x86_64-Linux :: symbolize_pc_inline.cpp
```

Reviewers: vitalybuka, kcc, filcab

Reviewed By: vitalybuka

Subscribers: #sanitizers

Tags: #sanitizers

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

Recommit "[X86] Calculate the needed size of the feature arrays in _cpu_indicator_init and getHostCPUName using the size of the feature enum."

Hopefully this version will fix the previously buildbot failure

Revert "[X86] Calculate the needed size of the feature arrays in _cpu_indicator_init and getHostCPUName using the size of the feature enum."

Seems to breaking build.

This reverts commit 5ac144fe.

[X86] Calculate the needed size of the feature arrays in _cpu_indicator_init and getHostCPUName using the size of the feature enum.

Move 0 initialization up to the caller so we don't need to know
the size.

I forgot to do this when I added then to _cpu_indicator_init.

libgcc has this enum encoding defined for a while, but their
detection code is missing. I've raised a bug with them so that
should get fixed soon.

[X86] Set the cpu_vendor in __cpu_indicator_init to VENDOR_OTHER if cpuid isn't supported on the CPU.

We need to set the cpu_vendor to a non-zero value to indicate
that we already called __cpu_indicator_init once.

This should only happen on a 386 or 486 CPU.

migrate away from the use of blacklist and whitelist.

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

Summary:
When enabling some malloc debug features on Android, multiple 32 bit
regions become exhausted, and the allocations fail. Allow allocations
to keep trying each bigger class in the Primary until it finds a fit.
In addition, some Android tests running on 32 bit fail sometimes due
to a running out of space in two regions, and then fail the allocation.

Reviewers: cryptoad

Reviewed By: cryptoad

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers

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

Summary:
Add a flag to omit the xray_fn_idx to cut size overhead and relocations
roughly in half at the cost of reduced performance for single function
patching.  Minor additions to compiler-rt support per-function patching
without the index.

Reviewers: dberris, MaskRay, johnislarry

Subscribers: hiraditya, arphaman, cfe-commits, #sanitizers, llvm-commits

Tags: #clang, #sanitizers, #llvm

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

Summary: we use the alias attribute, similar to what is done for ELF.

Reviewers: ZarkoCA, jasonliu, hubert.reinterpretcast, sfertile

Reviewed By: jasonliu

Subscribers: dberris, aheejin, mstorsjo, #sanitizers

Tags: #sanitizers

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

Summary: Add runtime support, adjust the tests and enable LSan.

Reviewers: vitalybuka, eugenis, uweigand, jonpa

Reviewed By: uweigand

Subscribers: mgorny, cfe-commits, #sanitizers

Tags: #clang, #sanitizers

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

Summary:
Before unwinding the stack, `__asan_handle_no_return` is supposed to
unpoison the entire stack - that is, remove the entries in the shadow
memory corresponding to stack (e.g. redzone markers around variables).
This does not work correctly if `__asan_handle_no_return` is called from
the alternate stack used in signal handlers, because the stack top is
read from a cache, which yields the default stack top instead of the
signal alternate stack top.

It is also possible to jump between the default stack and the signal
alternate stack. Therefore, __asan_handle_no_return needs to unpoison
both.

Reviewers: vitalybuka, kubamracek, kcc, eugenis

Reviewed By: vitalybuka

Subscribers: phosek, #sanitizers

Tags: #sanitizers

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

Summary: This adds a customization point to support unpoisoning of signal alternate stacks on POSIX.

Reviewers: vitalybuka

Reviewed By: vitalybuka

Subscribers: #sanitizers

Tags: #sanitizers

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

Summary:
Normally, the Origin is passed over TLS, which seems like it introduces unnecessary overhead. It's in the (extremely) cold path though, so the only overhead is in code size.

But with eager-checks, calls to __msan_warning functions are extremely common, so this becomes a useful optimization.

This can save ~5% code size.

Reviewers: eugenis, vitalybuka

Reviewed By: eugenis, vitalybuka

Subscribers: hiraditya, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

Brand index was a feature some Pentium III and Pentium 4 CPUs.
It provided an index into a software lookup table to provide a
brand name for the CPU. This is separate from the family/model.

It's unclear to me why this index being non-zero was used to
block checking family/model. None of the CPUs that had a non-zero
brand index are supported by __builtin_cpu_is or target
multi-versioning so this should have no real effect.

[X86] Combine to two feature variables in __cpu_indicator_init into an array and pass them around as pointer we can treat as an array.

This simplifies the indexing code to set and test bits.