Hwasan includes instructions in the prologue that mix the PC and SP and store
it into the stack ring buffer stored at __hwasan_tls. This is a thread_local
global exposed from the hwasan runtime. However, if TLS-mechanisms or the
hwasan runtime haven't been setup yet, it will be invalid to access __hwasan_tls.
This is the case for Fuchsia where we instrument libc, so some functions that
are instrumented but can run before hwasan initialization will incorrectly
access this global. Additionally, libc cannot have any TLS variables, so we
cannot weakly define __hwasan_tls until the runtime is loaded.
A way we can work around this is by moving the instructions into a hwasan
function that does the store into the ring buffer and creating a weak definition
of that function locally in libc. This way __hwasan_tls will not actually be
referenced. This is not our long-term solution, but this will allow us to roll
out hwasan in the meantime.
This patch includes:
- A new llvm flag for choosing to emit a libcall rather than instructions in the
prologue (off by default)
- The libcall for storing into the ringbuffer (__hwasan_record_frame_record)
Differential Revision: https://reviews.llvm.org/D128387
This is to finish the change started by D125816 , D126263 and D126577 (replace SANITIZER_MAC by SANITIZER_APPLE).
Dropping definition of SANITIZER_MAC completely, to remove any possible confusion.
Differential Revision: https://reviews.llvm.org/D129502
It is generally not a good idea to mix usage of glibc headers and Linux UAPI
headers (https://sourceware.org/glibc/wiki/Synchronizing_Headers). In glibc
since 7eae6a91e9b1670330c9f15730082c91c0b1d570 (milestone: 2.36), sys/mount.h
defines `fsconfig_command` which conflicts with linux/mount.h:
.../usr/include/linux/mount.h:95:6: error: redeclaration of ‘enum fsconfig_command’
Remove #include <linux/fs.h> which pulls in linux/mount.h. Expand its 4 macros manually.
Android sys/mount.h doesn't define BLKBSZGET and it still needs linux/fs.h.
In the long term we should move Linux specific definitions to sanitizer_platform_limits_linux.cpp
but this commit is easy to cherry pick into older compiler-rt releases.
Fix https://github.com/llvm/llvm-project/issues/56421
Reviewed By: #sanitizers, vitalybuka, zatrazz
Differential Revision: https://reviews.llvm.org/D129471
It is generally not a good idea to mix usage of glibc headers and Linux UAPI
headers (https://sourceware.org/glibc/wiki/Synchronizing_Headers). In glibc
since 7eae6a91e9b1670330c9f15730082c91c0b1d570 (milestone: 2.36), sys/mount.h
defines `fsconfig_command` which conflicts with linux/mount.h:
.../usr/include/linux/mount.h:95:6: error: redeclaration of ‘enum fsconfig_command’
Remove #include <linux/fs.h> which pulls in linux/mount.h. Expand its 4 macros manually.
Fix https://github.com/llvm/llvm-project/issues/56421
Reviewed By: #sanitizers, vitalybuka, zatrazz
Differential Revision: https://reviews.llvm.org/D129471
After https://reviews.llvm.org/D129237, the assumption
that any non-null data contains a valid vmar handle is no
longer true. Generally this code here needs cleanup, but
in the meantime this fixes errors on Fuchsia.
Differential Revision: https://reviews.llvm.org/D129331
This is a follow up to D118200 which applies a similar cleanup to
headers when using in-tree libc++ to avoid accidentally picking up
the system headers.
Differential Revision: https://reviews.llvm.org/D128035
This is a follow up to D118200 which applies a similar cleanup to
headers when using in-tree libc++ to avoid accidentally picking up
the system headers.
Differential Revision: https://reviews.llvm.org/D128035
We currently have an option to select C++ ABI and C++ library for tests
but there are runtimes that use C++ library, specifically ORC and XRay,
which aren't covered by existing options. This change introduces a new
option to control the use of C++ libray for these runtimes.
Ideally, this option should become the default way to select C++ library
for all of compiler-rt replacing the existing options (the C++ ABI
option could remain as a hidden internal option).
Differential Revision: https://reviews.llvm.org/D128036
While investigating another issue, I noticed that `MaybeReexec()` never
actually "re-executes via `execv()`" anymore. `DyldNeedsEnvVariable()`
only returned true on macOS 10.10 and below.
Usually, I try to avoid "unnecessary" cleanups (it's hard to be certain
that there truly is no fallout), but I decided to do this one because:
* I initially tricked myself into thinking that `MaybeReexec()` was
relevant to my original investigation (instead of being dead code).
* The deleted code itself is quite complicated.
* Over time a few other things were mushed into `MaybeReexec()`:
initializing `MonotonicNanoTime()`, verifying interceptors are
working, and stripping the `DYLD_INSERT_LIBRARIES` env var to avoid
problems when forking.
* This platform-specific thing leaked into `sanitizer_common.h`.
* The `ReexecDisabled()` config nob relies on the "strong overrides weak
pattern", which is now problematic and can be completely removed.
* `ReexecDisabled()` actually hid another issue with interceptors not
working in unit tests. I added an explicit `verify_interceptors`
(defaults to `true`) option instead.
Differential Revision: https://reviews.llvm.org/D129157
While investigating another issue, I noticed that `MaybeReexec()` never
actually "re-executes via `execv()`" anymore. `DyldNeedsEnvVariable()`
only returned true on macOS 10.10 and below.
Usually, I try to avoid "unnecessary" cleanups (it's hard to be certain
that there truly is no fallout), but I decided to do this one because:
* I initially tricked myself into thinking that `MaybeReexec()` was
relevant to my original investigation (instead of being dead code).
* The deleted code itself is quite complicated.
* Over time a few other things were mushed into `MaybeReexec()`:
initializing `MonotonicNanoTime()`, verifying interceptors are
working, and stripping the `DYLD_INSERT_LIBRARIES` env var to avoid
problems when forking.
* This platform-specific thing leaked into `sanitizer_common.h`.
* The `ReexecDisabled()` config nob relies on the "strong overrides weak
pattern", which is now problematic and can be completely removed.
* `ReexecDisabled()` actually hid another issue with interceptors not
working in unit tests. I added an explicit `verify_interceptors`
(defaults to `true`) option instead.
Differential Revision: https://reviews.llvm.org/D129157
Update the address tagging bitmask check to just see if
ZX_ARM64_FEATURE_ADDRESS_TAGGING_TBI is enabled rather than checking
if it's the only thing that's enabled.
Differential Revision: https://reviews.llvm.org/D129318
Unpoison by strlen(dest), as dn_expand
returns the size if the compressed name (src).
Reviewed By: kstoimenov
Differential Revision: https://reviews.llvm.org/D129244
Implements TLS descriptor relocations in JITLink ELF/AARCH64 backend and support the relevant runtime functions in ELFNixPlatform.
Unlike traditional TLS model, TLS descriptor model requires linker to return the "offset" from thread pointer via relocaiton not the actual pointer to thread local variable. There is no public libc api for adding new allocations to TLS block dynamically which thread pointer points to. So, we support this by taking delta from thread base pointer to the actual thread local variable in our allocated section.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D128601
Building the compiler-rt's AddressSanitizer for
the n32 MIPS ABI currently fails, due to a few reasons:
- defined(__mips64), which is set solely based on
the architecture type (32-bit/64-bit), was still used
in some places. Therefore, defined(__mips64) is swapped
with SANITIZER_MIPS64, which takes the ABI into account
as well - defined(__mips64) && _MIPS_SIM == ABI64.
- The n32 ABI still uses 64-bit *Linux* system calls,
even though the word size is 32 bits.
- After the transition to canonical system calls (D124212),
the n32 ABI still didn't use them, even though they
are supported.
Differential Revision: https://reviews.llvm.org/D127098
In my previous change [1], I added log output that made a test that
expected "no output" fail. The easiest solution is to only print the
new hint/warning when we at least ask for `verbosity=1`.
[1] https://reviews.llvm.org/D128936
Radar-Id: rdar://96437354
This patch was pushed for calixte@mozilla.com
- this function (Windows only) is called when gcda are dumped on disk;
- according to its documentation, it's only useful in case of hard failures, this is highly improbable;
- it drastically decreases the time in the tests and consequently it avoids timeouts when we use slow disks.
Differential Revision: https://reviews.llvm.org/D129128
Fuchsia has split overloaded nanosleep(0) for yielding to its own
dedicated syscall, so valid zero deadlines would just return.
Patch By: gevalentino
Differential Revision: https://reviews.llvm.org/D128748
On macOS 13+, dyld itself has moved into the shared cache. Looking it
up via vm_region_recurse_64() now causes spins/hangs/crashes. We use a
different set of dyld APIs to find the image header in the shared cache.
rdar://92131949
Differential Revision: https://reviews.llvm.org/D128936
With this change, fuzz targets may choose to return -1
to indicate that the input should not be added to the corpus
regardless of the coverage it generated.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D128749
This is a follow up to <LLVM reviews>/D127343, which was reverted due to test failures.
There are differences in handling of stat64/statfs64 calls by sanitizers between Linux and macOS. Versions of macOS starting with 10.6 drop the stat64/statfs64 APIs completely, relying on the linker to redirect stat/statfs to the appropriate 64 bit versions. Emitting variables needed by sanitizers is thus controlled by convoluted sets of conditions, involving Linux, IOS, macOS and Android, sprinkled around files.
This change clarifies it a bit, allowing to specify presence/absence of stat64/statfs64 for each platform, in a single location.
Please note that I wasn't able to test this change on platforms other than macOS and Linux Fedora 34. The previous attempt has caused test failures but couldn't figure out the context. I have a vague suspicion that they were Android and perhaps Fuchsia builds - and some build involving ppc64le, I don't have hardware handy to attempt a test there. Tried to tighten the conditions this time to clearly separate macOS from Linux, so Linux builds should behave same (sanitizerwise) as before the change. Will add people who reported the tests failing before as reviewers, so they can provide context should the change cause the test failures again.
Differential Revision: https://reviews.llvm.org/D128476
Pass on the default target triple of the host clang to the LLVM builds
within the `build_symbolizer.sh` script.
Differential Revision: https://reviews.llvm.org/D128731
Remove the `ar_to_bc.sh` helper script in the compiler-rt symbolizer
build. Instead use `llvm-link` directly as D81109 introduced the
capability to read archives. I just needed to add a new flag
`-ignore-non-bitcode` to avoid `llvm-link` aborting when it found a
non-bitcode file in the archive.
Differential Revision: https://reviews.llvm.org/D128729
Add a missing "#if !SANITIZER_GO" guard for a call to DumpProcessMap
in the Finalize hook (needed to build an updated Go race detector syso
image).
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D128641
We no longer support the use of LLVM_ENABLE_PROJECTS for libcxx and
libcxxabi. We don't use paths to libcxx and libcxxabi in compiler-rt.
Differential Revision: https://reviews.llvm.org/D126905
We no longer support the use of LLVM_ENABLE_PROJECTS for libcxx and
libcxxabi. We don't use paths to libcxx and libcxxabi in compiler-rt.
Differential Revision: https://reviews.llvm.org/D126905
This is a first step towards allowing programs to pre-link against the ORC
runtime, which would allow us to move some code that is currently in the LLVM
OrcTarget library into the ORC runtime instead.
The C API header has limited utility as-is, but serves as a minimal first step
and provides clients with tools for interacting with wrapper functions.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D127324
This reverts commit 99796d06db.
Hint: Looking here because your manual invocation of something in
'check-asan' broke? You need a new symbolizer (after D123538).
An upcoming patch will remove the internal metadata for global
variables. With D123534 and D123538, clang now emits DWARF debug info
for constant strings (the only global variable type it was missing), and
llvm-symbolizer is now able to symbolize all global variable addresses
(where previously it wouldn't give you the file:line information).
Move ASan's runtime over from the internal metadata to DWARF.
Differential Revision: https://reviews.llvm.org/D127552
This test was failing with the following error message if to run the test binary
directly, w/o using lit:
$ Sanitizer-x86_64-Test --gtest_filter=SanitizerCommon.ChainedOriginDepot*
...
[ RUN ] SanitizerCommon.ChainedOriginDepotStats
compiler-rt/lib/sanitizer_common/tests/sanitizer_chained_origin_depot_test.cpp:77: Failure
Expected: (stats1.allocated) > (stats0.allocated), actual: 196608 vs 196608
[ FAILED ] SanitizerCommon.ChainedOriginDepotStats (867 ms)
Since the ChainedOriginDepot* tests are not doing any cleanup, by the time
SanitizerCommon.ChainedOriginDepotStats test starts executing the depot
may not be empty, so there will be no allocation for the test.
This patch introduces ChainedOriginDepot::TestOnlyUnmap() API that deallocates
memory when requested. This makes sure underlying TwoLevelMap initiates
the expected allocation during the test.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D127621
Hint: Looking here because your manual invocation of something in
'check-asan' broke? You need a new symbolizer (after D123538).
An upcoming patch will remove the internal metadata for global
variables. With D123534 and D123538, clang now emits DWARF debug info
for constant strings (the only global variable type it was missing), and
llvm-symbolizer is now able to symbolize all global variable addresses
(where previously it wouldn't give you the file:line information).
Move ASan's runtime over from the internal metadata to DWARF.
Differential Revision: https://reviews.llvm.org/D127552
This is modeled after the half-precision fp support. Two new nodes are
introduced for casting from and to bf16. Since casting from bf16 is a
simple operation I opted to always directly lower it to integer
arithmetic. The other way round is more complicated if you want to
preserve IEEE semantics, so it's handled by a new __truncsfbf2
compiler-rt builtin.
This is of course very bare bones, but sufficient to get a semi-softened
fadd on x86.
Possible future improvements:
- Targets with bf16 conversion instructions can now make fp_to_bf16 legal
- The software conversion to bf16 can be replaced by a trivial
implementation under fast math.
Differential Revision: https://reviews.llvm.org/D126953
Rather than invoking the linker directly, let the compiler driver
handle it. This ensures that we use the correct linker in the case
of cross-compiling.
Differential Revision: https://reviews.llvm.org/D127828
This allows configuring LLVM unwinder separately from the C++ library
matching how we configure it in libcxx.
This also applies changes made to libunwind+libcxxabi+libcxx in D113253
to compiler-rt.
Differential Revision: https://reviews.llvm.org/D115674
ELF-based platforms currently support defining multiple static
initializer table sections with differing priorities, for example
.init_array.0 or .init_array.100; the default .init_array corresponds
to a priority of 65535. When building a shared library or executable,
the system linker normally sorts these sections and combines them into
a single .init_array section. This change adds the capability to
recognize ELF static initializers with priorities other than the
default, and to properly sort them by priority, to Orc and the Orc
runtime.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D127056
This change enables integrating orc::LLJIT with the ORCv2
platforms (MachOPlatform and ELFNixPlatform) and the compiler-rt orc
runtime. Changes include:
- Adding SPS wrapper functions for the orc runtime's dlfcn emulation
functions, allowing initialization and deinitialization to be invoked
by LLJIT.
- Changing the LLJIT code generation default to add UseInitArray so
that .init_array constructors are generated for ELF platforms.
- Integrating the ORCv2 Platforms into lli, and adding a
PlatformSupport implementation to the LLJIT instance used by lli which
implements initialization and deinitialization by calling the new
wrapper functions in the runtime.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D126492
There are differences in handling of stat64/statfs64 calls by sanitizers between Linux and macOS. Versions of macOS starting with 10.6 drop the stat64/statfs64 APIs completely, relying on the linker to redirect stat/statfs to the appropriate 64 bit versions. Emitting variables needed by sanitizers is thus controlled by convoluted sets of conditions, involving Linux, IOS, macOS and Android, sprinkled around files.
This change adresses it, allowing to specify presence/absence of stat64/statfs64 for each platform, in a single location. Also, it adresses the Android case which handles stat64, but not statfs64.
Adding Vitaly as a reviewer since he seems to be actively working on sanitizers, perhaps can comment on the Android bit
Differential Revision: https://reviews.llvm.org/D127343
Supports on Android but also from Linux 5.17
Reviewers: vitalybuka, eugenis
Reviewed-By: vitalybuka
Differential Revision: https://reviews.llvm.org/D127326
On FreeBSD AArch64 safestack needs to use __syscall to handle 64 bit arguments
Reviewed by: MaskRay, vitalybuka
Differential Revision: https://reviews.llvm.org/D125901
The stack pointer is stored in the second slot in the jump buffer on
AArch64. Use the correct slot value to read this rather than the
following register.
Reviewed by: melver
Differential Revision: https://reviews.llvm.org/D125762
As with 64 bit x86 use an offset in middle of the address space scaled up
to work with the full 48 bit space.
Reviewed by: MaskRay
Differential Revision: https://reviews.llvm.org/D125757
This reverts commit b37d84aa8d.
This broke aarch64 asan builders for fuchsia. I accidentally changed the allocator
settings for fuchsia on aarch64 because the new asan allocator settings use:
```
// AArch64/SANITIZER_CAN_USE_ALLOCATOR64 is only for 42-bit VMA
// so no need to different values for different VMA.
const uptr kAllocatorSpace = 0x10000000000ULL;
const uptr kAllocatorSize = 0x10000000000ULL; // 3T.
typedef DefaultSizeClassMap SizeClassMap;
```
rather than reaching the final `#else` which would use fuchsia's lsan config.
I believe this should've been fixed with 4b15e665f8
which landed after this initial patch, but I reverted too early before I
saw the builder turn green again.
This updates existing asan allocator settings to use the same allocator settings as what lsan uses for platforms where they already match.
Differential Revision: https://reviews.llvm.org/D126927
This way downstream tools that read sanitizer output can differentiate between OOM errors
reported by sanitizers from other sanitizer errors.
Changes:
- Introduce ErrorIsOOM for checking if a platform-specific error code from an "mmap" is an OOM err.
- Add ReportOOMError which just prepends this error message to the start of a Report call.
- Replace some Reports for OOMs with calls to ReportOOMError.
- Update necessary tests.
Differential Revision: https://reviews.llvm.org/D127161
Repalce the fixed buffer in SymbolizerProcess with InternalScopedString,
and simply append to it when reading data.
Fixes#55460
Reviewed By: vitalybuka, leonardchan
Differential Revision: https://reviews.llvm.org/D126580
ARM EHABI isn't signalled by any specific compiler builtin define,
but is implied by the lack of defines specifying any other
exception handling mechanism, `__USING_SJLJ_EXCEPTIONS__` or
`__ARM_DWARF_EH__`.
As Windows SEH also can be used for unwinding, check for the
`__SEH__` define too, in the same way.
This is the same change as 4a3722a2c3 /
D126866, applied on the compiler-rt builtins gcc_personality_v0
function.
Differential Revision: https://reviews.llvm.org/D126863
This interceptor only addresses writes to inputs. Reads of inputs are not checked.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D126851
The script uses llvm-link to link LLVM bitcode files.
5426da8ffa used -DLLVM_DISABLE_ASSEMBLY_FILES=ON
to ignore object files compiled from lib/Support/BLAKE3/*.S.
A better approach (which fits Bazel better) is to ignore non-bitcode files.
Reviewed By: akyrtzi
Differential Revision: https://reviews.llvm.org/D126728
sanitizer_intercept_overriders.h might override SANITIZER_INTERCEPT_CRYPT_R to
be undefined. There's no need to require crypt.h in that case.
(The motivation is that crypt() moved from glibc into its own package at some
point, which makes intercepting it and building with a single sysroot that
supports both pre-bullseye and post-bullseye a bit hairy.)
Differential Revision: https://reviews.llvm.org/D126696
Don't build atomic fetch nand libcall functions when the required
compiler builtin isn't available. Without this compiler-rt can't be
built with LLVM 13 or earlier.
Not building the libcall functions isn't optimal, but aligns with the
usecase in FreeBSD where compiler-rt from LLVM 14 is built with an LLVM
13 clang and no LLVM 14 clang is built.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D126710
Previous couple commits replaced SANITIZER_MAC with SANITIZER_APPLE in bulk.
This change will prompt anyone still trying to use SANITIZER_MAC to rename.
Differential Revision: https://reviews.llvm.org/D126577
GCC recently started setting constructor priority on init_have_lse_atomics [1]
to avoid undefined initialization order with respect to other initializers,
causing accidental use of ll/sc intrinsics on targets where this was not
intended (which presents a minor performance problem as well as a
compatibility problem for users wanting to use the rr debugger). I initially
thought compiler-rt does not have the same issue as libgcc, since it looks
like we're already setting init priority on the constructor.
Unfortuantely, it does not appear that the HAVE_INIT_PRIORITY check is ever
performed anyway, so despite appearances the init priority was not actually
applied. Fix that by applying the init priority unconditionally. It has been
supported in clang ever since it was first introduced and in any case for
more than 14 years in both gcc and clang. MSVC is already excluded from this
code path and we're already using constructors with init priority elsewhere
in compiler-rt without additional check (though mostly in the sanitizer
runtime, which may have more narrow target support). Regardless, I believe
that for our supported compilers, if they support the constructor attribute,
they should also support init priorities.
While we're here, change the init priority from 101, which is the highest
priority for end user applications, to instead use one of the priority levels
reserved for implementations (1-100; lower integers are higher priority).
GCC ended up using `90`, so this commit aligns the value in compiler-rt
to the same value to ensure that there are no subtle initialization order
differences between libgcc and compiler-rt.
[1] 75c4e4909a
Differential Revision: https://reviews.llvm.org/D126424
Sanitizers ignore flag allocator_may_return_null=1 in strndup() calls.
When OOM is emulated, this causes to the unexpected crash.
Committed by pgousseau on behalf of "Kostyantyn Melnik, kmnls.kmnls@gmail.com"
Reviewed by: pgousseau
Differential Revision: https://reviews.llvm.org/D126452
This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816)
Performed a global search/replace as in title against LLVM sources
Differential Revision: https://reviews.llvm.org/D126263
While attempting to get the 64-bit lsan allocator working for Fuchsia, I
noticed this function would incorrectly return false for pointers returned
by the 64-bit allocator. On AArch64, this function attempts to get the VMA
size dynamically by counting the number of leading zeros from the function
frame address. This will fail if the frame address is significantly below an
allocated pointer (that is, the frame address has more leading zeros than an
allocated pointer). This is possible on Fuchsia and linux (when not called
from the initial thread stack).
It seems the intended use of this function is to speed up pointer scanning by
filtering out addresses that user code might not be able to access. Other
platforms this check is done on seem to hardcode the VMA size/shift, so it
seems appropriate to do this for aarch64 as well. This implies pointers on
aarch64 where the VMA size is <64 will pass through, but bad pointers will
still be caught by subsequent scan checks.
This patch also renames the function to something more fitting of what it's
trying to do.
Differential Revision: https://reviews.llvm.org/D123814
Initial introduction of the new macro before obsoleting the old one - the old name was really confusing.
Also moved SANITIZER_WATCHOS and SANITIZER_TVOS definitions under common #if defined(__APPLE__) block
Differential Revision: https://reviews.llvm.org/D125816
The spinlock requires that lock-free operations are available;
otherwise, the implementation just calls itself. As discussed in
D120026.
Differential Revision: https://reviews.llvm.org/D123080
On arm64 the read/write flag is set on the esr register.
Adding this flag check for arm64 enables a more accurate
print out for sanitizer signal reports and matches the
behavior on x86.
Fixes bug: https://bugs.llvm.org/show_bug.cgi?id=27543https://github.com/google/sanitizers/issues/653
These tests are now passing:
SanitizerCommon-asan-arm64-Darwin :: Posix/illegal_read_test.cpp
SanitizerCommon-asan-arm64-Darwin :: Posix/illegal_write_test.cpp
SanitizerCommon-asan-arm64e-Darwin :: Posix/illegal_read_test.cpp
SanitizerCommon-asan-arm64e-Darwin :: Posix/illegal_write_test.cpp
SanitizerCommon-tsan-arm64-Darwin :: Posix/illegal_read_test.cpp
SanitizerCommon-tsan-arm64-Darwin :: Posix/illegal_write_test.cpp
SanitizerCommon-tsan-arm64e-Darwin :: Posix/illegal_read_test.cpp
SanitizerCommon-tsan-arm64e-Darwin :: Posix/illegal_write_test.cpp
SanitizerCommon-ubsan-arm64-Darwin :: Posix/illegal_read_test.cpp
SanitizerCommon-ubsan-arm64-Darwin :: Posix/illegal_write_test.cpp
SanitizerCommon-ubsan-arm64e-Darwin :: Posix/illegal_read_test.cpp
SanitizerCommon-ubsan-arm64e-Darwin :: Posix/illegal_write_test.cpp
rdar://92104440
Differential Revision: https://reviews.llvm.org/D125416
Also enable on X86_64.
The directory would change during the test execution. This should not
necessarily prevent us from indexing a directory (a user might
potentially do that if they specify a parent directory of the actual
symbols directory, and change unrelated files).
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D125143
The globals are better expressed as members of the Symbolizer, and all
functions operating on it should be methods instead.
Also using the standard idiom of wrapping the main code in
`if __name__ == '__main__'`.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D125032
This changes the ELFNix platform Orc runtime to use, when available,
the __unw_add_dynamic_eh_frame_section interface provided by libunwind
for registering .eh_frame sections loaded by JITLink. When libunwind
is not being used for unwinding, the ELFNix platform detects this and
defaults to the __register_frame interface provided by libgcc_s.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D114961
The globals are better expressed as members of the Symbolizer, and all
functions operating on it should be methods instead.
Also using the standard idiom of wrapping the main code in
`if __name__ == '__main__'`.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D125032
D116208 (commit 1298273e82) added FP_XSTATE_MAGIC1.
However, when building with glibc < 2.16 for backward-dependency
compatibility, it is not defined - and the build breaks.
Note: The define comes from Linux's asm/sigcontext.h but the
file uses signal.h which includes glibc's bits/sigcontext.h - which
is synced from the kernel's file but lags behind.
Solution: For backward compatility with ancient systems, define
FP_XSTATE_MAGIC1 if undefined.
//For the old systems, we were building with Linux kernel 3.19 but to support really old glibc systems, we build with a sysroot of glibc 2.12. While our kernel (and the users' kernels) have FP_XSTATE_MAGIC1, glibc 2.12 is too old. – With this patch, building the sanitizer libs works again. This showed up for us today as GCC mainline/13 has now synced the sanitizer libs.//
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D124927
This patch switches the PGO implementation on AIX from using the runtime
registration-based section tracking to the __start_SECNAME/__stop_SECNAME
based. In order to enable the recognition of __start_SECNAME/__stop_SECNAME
symbols in the AIX linker, the -bdbg:namedsects:ss needs to be used.
Reviewed By: jsji, MaskRay, davidxl
Differential Revision: https://reviews.llvm.org/D124857
D123200 did not include the generic sources, which means that only the
AVR-specific sources were compiled. With this change, generic sources
are included as expected.
Tested with the following commands:
cmake -G Ninja -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=avr -DCOMPILER_RT_BAREMETAL_BUILD=1 -DCMAKE_C_COMPILER=clang-14 -DCMAKE_C_FLAGS="--target=avr -mmcu=avr5 -nostdlibinc -mdouble=64" ../path/to/builtins
ninja
Differential Revision: https://reviews.llvm.org/D124969
Previously the default was long, which is 32-bit on AVR. But avr-gcc
expects a smaller value: it reads the return value from r24.
This is actually a regression from https://reviews.llvm.org/D98205.
Before D98205, the return value was an enum (which was 2 bytes in size)
which was compatible with the 1-byte return value that avr-gcc was
expecting. But long is 4 bytes and thus places the significant return
value in a different register.
Differential Revision: https://reviews.llvm.org/D124939
Fixes:
tsan/tsan_shadow.h:93:32: warning: enumerated and non-enumerated type in conditional expression [-Wextra]
tsan/tsan_shadow.h:94:44: warning: enumerated and non-enumerated type in conditional expression [-Wextra]
Differential Revision: https://reviews.llvm.org/D124828
After cd0a5889d7, unittest would run in shard mode where many tests
share a single process. Need to clear some global state to make the test
results stable.
Reviewed By: thetruestblue, rsundahl
Differential Revision: https://reviews.llvm.org/D124591
First check for clang::fallthrough attribute that resolves:
sanitizer_stack_store.cpp:258:7: error: use of the 'fallthrough'
attribute is a C++17 extension [-Werror,-Wc++17-attribute-extensions]
Use the pragma only when __clang__ is defined.
Fixes:
sanitizer_common_libcdep.cpp:101: warning: ignoring ‘#pragma clang diagnostic’ [-Wunknown-pragmas]
Differential Revision: https://reviews.llvm.org/D124829
Fixes:
sanitizer_stack_store.cpp:257:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
when being built with GCC.
Differential Revision: https://reviews.llvm.org/D124832
These "new" syscalls have been added in 2.6.16, more than 16 years ago.
Surely that's enough time to migrate. Glibc 2.33 is using them on both
i386 and x86_64. Android has an selinux filter to block the legacy
syscalls in the apps.
Differential Revision: https://reviews.llvm.org/D124212
By default -fsanitize=address already compiles with this check, why not use it.
For compatibly it can be disabled with env ASAN_OPTIONS=detect_stack_use_after_return=0.
Reviewed By: eugenis, kda, #sanitizers, hans
Differential Revision: https://reviews.llvm.org/D124057
An application can use the mere fact of epoll_wait returning an fd
as synchronization with the write on the fd that triggered the notification.
This pattern come up in an internal networking server (b/229276331).
If an fd is added to epoll, setup a link from the fd to the epoll fd
and use it for synchronization as well.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D124518
Temporarily revert the option to fix
https://bugs.chromium.org/p/chromium/issues/detail?id=1319387
This reverts option default and documentation of the commit. Test
changes are not being reverted as they are improvement and break
reliance on option defaults.
Additional memory usage is a problem on mobile devices with low memory.
Even heavy thread desktop programs may need some FakeStack tunning.
This reverts commit 4b4437c084.
Apply this in add_compiler_rt_runtime instead of manually adding it
to the individual projects. This applies the option on more
parts of compiler-rt than before, but should ideally not make any
difference assuming the other runtimes that lacked the option
also were C11 compatible.
Not marking this as required, to match the existing behaviour (where
`-std=c11` was added only if supported by the compiler).
This was suggested during the review of D110005.
Differential Revision: https://reviews.llvm.org/D124343
from compiler-rt/lib/tsan
[NFC] As part of using inclusive language within the llvm project, this
patch rewords comments to remove sanity check and sanity test.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D124390
By default -fsanitize=address already compiles with this check,
why not use it.
For compatibly it can be disabled with env ASAN_OPTIONS=detect_stack_use_after_return=0.
Reviewed By: eugenis, kda, #sanitizers, hans
Differential Revision: https://reviews.llvm.org/D124057
These "new" syscalls have been added in 2.6.16, more than 16 years ago.
Surely that's enough time to migrate. Glibc 2.33 is using them on both
i386 and x86_64. Android has an selinux filter to block the legacy
syscalls in the apps.
Differential Revision: https://reviews.llvm.org/D124212
Fixes llvm-project/compiler-rt/test/asan/TestCases/null_deref.cpp on
macOS/aarch64.
The bp (base pointer) variable was being loaded from register LR and
not FP on aarch64 (except for this narrow case):
defined(__IPHONE_8_0) && __IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_8_0
Without a valid bp from the FP register, it is not possible to traverse
previous frames for a complete stack trace. The rationale for fetching
the LR as the bp for all cases except above is not clear but since the
FP register is the canonical register for use as the frame pointer, this
commit removes the restriction above for unconditional use all aarch64.
rdar://91587039
Differential Revision: https://reviews.llvm.org/D124140
InstrProfilingPlatformLinux.c already provides these symbols. Linker order
saved us from noticing before.
Reviewed By: mcgrathr
Differential Revision: https://reviews.llvm.org/D124136
1. Add correct pc, sp and bp for FreeBSD.
2. Since there's no personality.h header on FreeBSD, move SANITIZER_PPC64V2
case below FREEBSD case.
3. __ppc_get_timebase_freq() is glibc-specific. Add a shim for FreeBSD that
does the same.
Looks like when the VE support was added it was added a few lines below where it should have been.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D123439
Current check assumes iOS as the only Apple devices running arm64.
```#if SANITIZER_MAC && !(defined(__arm64__) && SANITIZER_IOS)```
Stops Apple Silicon from being flagged as requiring unique RTTI.
This introduced unexpected behavior within the sanitizer.
rdar://91446703
Differential Revision: https://reviews.llvm.org/D123736
Usually when we generated stacktraces the process is in error state, so
running hooks may crash the process and prevent meaningfull error report.
Symbolizer, unwinder and pthread are potential source of mallocs.
https://b.corp.google.com/issues/228110771
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D123566
Usually when we generated stacktraces the process is in error state, so
running hooks may crash the process and prevent meaningfull error report.
Symbolizer, unwinder and pthread are potential source of mallocs.
https://b.corp.google.com/issues/228110771
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D123566
This reverts commit 63f2d1f4d4.
I don't quite understand why, but this causes a linker error for
me and a number of buildbots:
/home/npopov/repos/llvm-project/compiler-rt/lib/ubsan/../sanitizer_common/sanitizer_stacktrace.h:130: error: undefined reference to '__sanitizer::BufferedStackTrace::UnwindImpl(unsigned long, unsigned long, void*, bool, unsigned int)'
ubsan_GetStackTrace (from 52b751088b) called by
~ScopeReport leaves top/bottom zeroes in the
`!WillUseFastUnwind(request_fast_unwind)` code path.
When BufferedStackTrace::Unwind falls back to UnwindFast,
`if (stack_top < 4096) return;` will return early, leaving just one frame in the stack trace.
Fix this by always initializing top/bottom like 261d6e05d5.
Reviewed By: eugenis, yln
Differential Revision: https://reviews.llvm.org/D123562
Tested on an example callstack with misplaced binaries from Android.
Tested Regex against callstack without Build ID to confirm it still works.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D123437
This keeps the test behavior unchanged when CLANG_DEFAULT_PIE_ON_LINUX switches
to ON by default.
Note: current clang --target=mips64el-linux-gnu -fpie -pie -fuse-ld=lld
does not link with C++ exceptions, using -pie would lead to
```
ld.lld: error: cannot preempt symbol: DW.ref.__gxx_personality_v0
...
ld.lld: error: relocation R_MIPS_64 cannot be used against local symbol; recompile with -fPIC
...
```
when linking `ScudoUnitTests`: https://lab.llvm.org/buildbot/#/builders/169/builds/7311/steps/18/logs/stdio
According to the RFC [0], this review contains the compiler-rt parts of large integer divison for _BitInt.
It adds the functions
```
/// Computes the unsigned division of a / b for two large integers
/// composed of n significant words.
/// Writes the quotient to quo and the remainder to rem.
///
/// \param quo The quotient represented by n words. Must be non-null.
/// \param rem The remainder represented by n words. Must be non-null.
/// \param a The dividend represented by n + 1 words. Must be non-null.
/// \param b The divisor represented by n words. Must be non-null.
/// \note The word order is in host endianness.
/// \note Might modify a and b.
/// \note The storage of 'a' needs to hold n + 1 elements because some
/// implementations need extra scratch space in the most significant word.
/// The value of that word is ignored.
COMPILER_RT_ABI void __udivmodei5(su_int *quo, su_int *rem, su_int *a,
su_int *b, unsigned int n);
/// Computes the signed division of a / b.
/// See __udivmodei5 for details.
COMPILER_RT_ABI void __divmodei5(su_int *quo, su_int *rem, su_int *a, su_int *b,
unsigned int words);
```
into builtins.
In addition it introduces a new "bitint" library containing only those new functions,
which is meant as a way to provide those when using libgcc as runtime.
[0] https://discourse.llvm.org/t/rfc-add-support-for-division-of-large-bitint-builtins-selectiondag-globalisel-clang/60329
Differential Revision: https://reviews.llvm.org/D120327
All platforms return the main executable as the first dl_phdr_info.
FreeBSD, NetBSD, Solaris, and Linux-musl place the executable name
in the dlpi_name field of this entry. It appears that only Linux-glibc
uses the empty string.
To make this work generically on all platforms, unconditionally
skip the first object (like is currently done for FreeBSD and NetBSD).
This fixes first DSO detection on Linux-musl. It also would likely
fix detection on Solaris/Illumos if it were to gain PIE support
(since dlpi_addr would not be NULL).
Additionally, only skip the Linux VDSO on linux.
Finally, use the empty string as the "seen first dl_phdr_info"
marker rather than (char *)-1. If there was no other object, we
would try to dereference it for a string comparison.
Reviewed By: MaskRay, vitalybuka
Differential Revision: https://reviews.llvm.org/D119515
Compiler-rt cross-compile for ARMv5 fails because D99282 made it an error if DMB
is used for any pre-ARMv6 targets. More specifically, the "#error only supported
on ARMv6+" added in D99282 will cause compilation to fail when any source file
which includes assembly.h are compiled for pre-ARMv6 targets. Since the only
place where DMB is used is syn-ops.h (which is only included by
arm/sync_fetch_and_* and these files are excluded from being built for older
targets), this patch moves the definition there to avoid the issues described
above.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D123105
The previous check for interceptors used `pthread_create()` which is not
available on DriverKit. We need an intercepted symbol that satisfies
the following constraints:
- Symbol is available in DriverKit
- Symbol is provided by simulator runtime dylibs (`dlsym()` fails to
look up host-provided symbols)
`puts()` satisfies all of the above constraints.
rdar://87895539
Reviewed By: yln
Differential Revision: https://reviews.llvm.org/D123245
This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.
Differential Revision: https://reviews.llvm.org/D120682
This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.
Differential Revision: https://reviews.llvm.org/D120682
Currently LoadedModule provides max_executable_address.
Replace it with just max_address.
It's only used for printing for human inspection and since
modules are non-overlapping, max_address is as good as max_executable_address
for matching addresses/PCs against modules (I assume it's used for that).
On the hand, max_address is more general and can used to match e.g. data addresses.
I want to use it for that purpose in future changes.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D122906
Update the hardware CRC32 logic in scudo to support using `-mcrc32`
instead of `-msse4.2`. The CRC32 intrinsics use the former flag
in the newer compiler versions, e.g. in clang since 12fa608af4.
With these versions of clang, passing `-msse4.2` is insufficient
to enable the instructions and causes build failures when `-march` does
not enable CRC32 implicitly:
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.cpp:20:10: error: always_inline function '_mm_crc32_u32' requires target feature 'crc32', but would be inlined into function 'computeHardwareCRC32' that is compiled without support for 'crc32'
return CRC32_INTRINSIC(Crc, Data);
^
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.h:27:27: note: expanded from macro 'CRC32_INTRINSIC'
# define CRC32_INTRINSIC FIRST_32_SECOND_64(_mm_crc32_u32, _mm_crc32_u64)
^
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/../sanitizer_common/sanitizer_platform.h:132:36: note: expanded from macro 'FIRST_32_SECOND_64'
# define FIRST_32_SECOND_64(a, b) (a)
^
1 error generated.
For backwards compatibility, use `-mcrc32` when available and fall back
to `-msse4.2`. The `<smmintrin.h>` header remains in use as it still
works and is compatible with GCC, while clang's `<crc32intrin.h>`
is not.
Use __builtin_ia32*() rather than _mm_crc32*() when using `-mcrc32`
to preserve compatibility with GCC. _mm_crc32*() are aliases
to __builtin_ia32*() in both compilers but GCC requires `-msse4.2`
for the former, while both use `-mcrc32` for the latter.
Originally reported in https://bugs.gentoo.org/835870.
Differential Revision: https://reviews.llvm.org/D122789
leonardchan