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
The `-fuse-ld=lld` check might succeed because there's a system lld,
but that lld may be out-of-date which would cause any tests that
attempt to use for LTO fail. This was observed on some of the bots.
Differential Revision: https://reviews.llvm.org/D81629
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
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
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
Summary: As the parent process would return 0 independent of whether the child succeeded, assertions in the child would be ignored.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D82400
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.
Keep deprecated -fsanitize-coverage-{white,black}list as aliases for compatibility for now.
Reviewed By: echristo
Differential Revision: https://reviews.llvm.org/D82244
At this point in this code:
- COMPILER_RT_DEFAULT_TARGET_TRIPLE is "i686-linux-android"
- arch is "i386"
The get_compiler_rt_target function currently turns that into:
i686-android-linux-android
The ${COMPILER_RT_OS_SUFFIX} is "-android" and redundant, so stop
adding it.
The get_compiler_rt_target() function is used for the
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR mode that isn't normally used with
Android.
Differential Revision: https://reviews.llvm.org/D82150
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:
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.
Summary:
The `execute_external` global variable is defined in [`lit.common.cfg.py`](fcfb3170a7/compiler-rt/test/lit.common.cfg.py (L18-L27)) and used here (on lines 23 and 39). However, this variable is not visible in configs that are loaded independently.
Explicitly assign it to the correct value to avoid `NameError`.
Reviewers: compnerd, phosek
Reviewed By: compnerd, phosek
Subscribers: dberris, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79892
Summary: Refactor the current global header iteration to be callback-based, and add a feature that reports the size of the global variable during reporting. This allows binaries without symbols to still report the size of the global variable, which is always available in the HWASan globals PT_NOTE metadata.
Reviewers: eugenis, pcc
Reviewed By: pcc
Subscribers: mgorny, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D80599
Having the input dumped on failure seems like a better
default: I debugged FileCheck tests for a while without knowing
about this option, which really helps to understand failures.
Remove `-dump-input-on-failure` and the environment variable
FILECHECK_DUMP_INPUT_ON_FAILURE which are now obsolete.
Differential Revision: https://reviews.llvm.org/D81422
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
Gui Andrade