Commit Graph

12066 Commits

Author SHA1 Message Date
Vitaly Buka 341ee9c029 [NFC][asan] Fix Condition annotation after 30bbb73bb4 2022-08-08 19:20:06 -07:00
Fangrui Song 474145c0b2 [CMake] Build lib/gwp_asan/tests with -std=c++17
With the recent llvm-project C++17 switch (D130689), gwp_asan/tests may fail to
link with some versions of GCC (https://github.com/llvm/llvm-project/issues/56994):

> backtrace.cpp:(.text+0xca6): undefined reference to `gwp_asan::AllocationMetadata::kMaxTraceLengthToCollect'

I cannot reproduce this issue by myself, but notice that currently
lib/gwp_asan/*.cpp get -std=c++17 while lib/gwp_asan/tests/*.cpp don't
(therefore may use -std=g++14 default from Clang and older GCC). Using -std=c++17
for lib/gwp_asan/tests will ensure that backtrace.cpp uses inline variable and will assuredly avoid the
possible GCC issue.

In the long-term, we should add -std=c++17 to a central place like generate_compiler_rt_tests.

Reviewed By: dyung

Differential Revision: https://reviews.llvm.org/D131440
2022-08-08 17:51:17 -07:00
Vitaly Buka 30bbb73bb4 [NFC][asan] Add LIKELY/UNLIKELY on hot memcpy paths 2022-08-08 16:25:56 -07:00
Vitaly Buka 67c06c4731 [NFC][asan] Clang-format a file 2022-08-08 16:21:35 -07:00
Diana Picus 8342ea6eac [scudo] Try to fix standalone build on armv7
When linking scudo standalone on armv7, it can't find symbols related to
unwinding (e.g. __aeabi_unwind_cpp_pr0). This is because it is passing
--unwindlib=none. This patch hacks around the issue by adding
COMPILER_RT_UNWINDER_LINK_LIBS to the link line.

I don't know anything about scudo, so I'm not sure what the original
intention was.

See also https://github.com/llvm/llvm-project/issues/56900

Differential Revision: https://reviews.llvm.org/D131250
2022-08-08 10:19:12 +02:00
luxufan ace6e172bd [RISCV] Support fe_getround and fe_raise_inexact in builtins
Reviewed By: luismarques

Differential Revision: https://reviews.llvm.org/D128240
2022-08-08 09:58:27 +08:00
Lang Hames 608131b1f9 [ORC-RT] Fix missing #include <string_view>s.
1dcff823db updated the ORC runtime to use std::string_view, rather than its
own placeholder class (__orc_rt::string_view), but failed to add these
includes.
2022-08-07 14:32:28 -07:00
Lang Hames aa2a3196e2 [ORC-RT] Remove a stray __orc_rt::string_view helper.
This function was accidentally left in after 1dcff823db.
2022-08-07 11:23:09 -07:00
Lang Hames 1dcff823db [ORC-RT] Drop __orc_rt::string_view now that we have c++17.
b1356504e6 enabled the use of c++17 features in LLVM, which means that we can
drop the ORC runtime's placeholder string_view implemention in favor of
std::string_view.
2022-08-07 09:37:09 -07:00
Keith Smiley 9ec4ddd224
[Sanitizer][Darwin] Support OS versions before DRIVERKIT
Fixes https://github.com/llvm/llvm-project/issues/56960

Differential Revision: https://reviews.llvm.org/D131288
2022-08-05 15:39:05 -07:00
Florian Mayer 29ff262761 [HWASan] Remove incorrect unreachable.
This function could be called wih access_info & 0x20 or with
flags()->halt_on_error, in which case HandleTagMismatch returns (is not
fatal).

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D131279
2022-08-05 13:14:08 -07:00
Than McIntosh 24a62bfe9a tsan: fix bug in shadow reset introduced in D128909
Correct a bug in the code that resets shadow memory introduced as part
of a previous change for the Go race detector (D128909). The bug was
that only the most recently added shadow segment was being reset, as
opposed to the entire extent of the segment created so far. This
fixes a bug identified in Google internal testing (b/240733951).

Differential Revision: https://reviews.llvm.org/D131256
2022-08-05 11:36:58 -04:00
Nikita Popov 542977d438 Revert "[compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux"
As mentioned in https://reviews.llvm.org/D121379#3690593, this
change broke the build of compiler-rt targeting powerpc using GCC.
The 32-bit powerpc target is not supposed to emit 128-bit libcalls
-- if it does, then that's a backend bug and needs to be fixed there.

This reverts commit 8f24a56a3a.

Differential Revision: https://reviews.llvm.org/D130988
2022-08-05 16:43:44 +02:00
Ben Langmuir adea1fa047 [orc-rt] Fix swift protocol metadata registration
The __swif5_proto and __swift5_protos sections had their meaning
inverted. Fix, and rename the arrays so it is more obvious which is
which.

Differential Revision: https://reviews.llvm.org/D131206
2022-08-04 14:55:24 -07:00
Fangrui Song 71e8f79601 [ubsan] Make TypeCheckKinds const. NFC
Move it from .data to .data.rel.ro
2022-08-03 11:02:22 -07:00
Phoebe Wang b17c89d151 Revert "[compiler-rt] [builtins] Detect _Float16 support at compile time"
This reverts commit ce6d40f5c2.

Revert due to it broke the sanitizer-windows buildbot: https://lab.llvm.org/buildbot/#/builders/127/builds/33583/steps/4/logs/stdio
2022-07-30 09:41:33 +08:00
Dimitry Andric ce6d40f5c2 [compiler-rt] [builtins] Detect _Float16 support at compile time
Instead of detecting `_Float16` support at CMake configuration time,
detect it at compile time by checking for the predefined (by the
compiler) macro `__FLT16_MAX__` instead.

This solves the issue where compiler-rt is built simultaneously for both
x86_64 and i386 targets, and the CMake configuration uses x86_64
compilation to detect `_Float16` support, while it may not be supported
by the i386 target (if it does not have SSE2).

While here, rename `COMPILERT_RT_HAS_FLOAT16` to `CRT_HAS_FLOAT16`, to
conform more to the naming style used in `int_lib.h` and `int_types.h`.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D130718
2022-07-29 20:58:52 +02:00
Than McIntosh b6374437af tsan: capture shadow map start/end on init and reuse in reset
Capture the computed shadow begin/end values at the point where the
shadow is first created and reuse those values on reset. Introduce new
windows-specific function "ZeroMmapFixedRegion" for zeroing out an
address space region previously returned by one of the MmapFixed*
routines; call this function (on windows) from DoResetImpl
tsan_rtl.cpp instead of MmapFixedSuperNoReserve.

See https://github.com/golang/go/issues/53539#issuecomment-1168778740
for context; intended to help with updating the syso for Go's
windows/amd64 race detector.

Differential Revision: https://reviews.llvm.org/D128909
2022-07-26 10:04:39 -04:00
Dmitry Vyukov 7ec308715c tsan: prevent pathological slowdown for spurious races
Prevent the following pathological behavior:
Since memory access handling is not synchronized with DoReset,
a thread running concurrently with DoReset can leave a bogus shadow value
that will be later falsely detected as a race. For such false races
RestoreStack will return false and we will not report it.
However, consider that a thread leaves a whole lot of such bogus values
and these values are later read by a whole lot of threads.
This will cause massive amounts of ReportRace calls and lots of
serialization. In very pathological cases the resulting slowdown
can be >100x. This is very unlikely, but it was presumably observed
in practice: https://github.com/google/sanitizers/issues/1552
If this happens, previous access sid+epoch will be the same for all of
these false races b/c if the thread will try to increment epoch, it will
notice that DoReset has happened and will stop producing bogus shadow
values. So, last_spurious_race is used to remember the last sid+epoch
for which RestoreStack returned false. Then it is used to filter out
races with the same sid+epoch very early and quickly.
It is of course possible that multiple threads left multiple bogus shadow
values and all of them are read by lots of threads at the same time.
In such case last_spurious_race will only be able to deduplicate a few
races from one thread, then few from another and so on. An alternative
would be to hold an array of such sid+epoch, but we consider such scenario
as even less likely.
Note: this can lead to some rare false negatives as well:
1. When a legit access with the same sid+epoch participates in a race
as the "previous" memory access, it will be wrongly filtered out.
2. When RestoreStack returns false for a legit memory access because it
was already evicted from the thread trace, we will still remember it in
last_spurious_race. Then if there is another racing memory access from
the same thread that happened in the same epoch, but was stored in the
next thread trace part (which is still preserved in the thread trace),
we will also wrongly filter it out while RestoreStack would actually
succeed for that second memory access.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D130269
2022-07-25 10:40:11 +02:00
Dmitry Vyukov 7505cc301f tsan: remove tracking of racy addresses
We used to deduplicate based on the race address to prevent lots
of repeated reports about the same race.

But now we clear the shadow for the racy address in DoReportRace:

  // This prevents trapping on this address in future.
  for (uptr i = 0; i < kShadowCnt; i++)
    StoreShadow(&shadow_mem[i], i == 0 ? Shadow::kRodata : Shadow::kEmpty);

It should have the same effect of not reporting duplicates
(and actually better because it's automatically reset when the memory is reallocated).

So drop the address deduplication code. Both simpler and faster.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D130240
2022-07-25 10:33:26 +02:00
Khem Raj 8f24a56a3a [compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux
clang generates calls to these intrinsics when used for ppc32/linux, when using libgcc this works ok but when using compiler-rt for rtlib it fails with missing intrinsic symbols. also see [1]

[1] https://lists.llvm.org/pipermail/llvm-dev/2014-May/072784.html

Reviewed By: MaskRay, glaubitz

Differential Revision: https://reviews.llvm.org/D121379
2022-07-24 10:17:22 -07:00
Dimitrije Milosevic 2bfb0fcb51 [MIPS][compiler-rt] Fix stat struct's size for O32 ABI
Add the MIPS O32 ABI value for the stat struct's size.

Differential Revision: https://reviews.llvm.org/D129749.
2022-07-23 11:53:00 +02:00
Ivan Trofimov 15e9b1d0c0 [libasan] Remove 4Mb stack limit for swapcontext unpoisoning
Reviewed By: vitalybuka, eugenis

Differential Revision: https://reviews.llvm.org/D129219
2022-07-22 17:37:44 -07:00
Vitaly Buka c93e4b6b2c [asan] Reset stack bounds of context
ClearShadowMemoryForContextStack assumes that context contains the stack
bounds. This is not true for a context from getcontext or oucp of
swapcontext.

Reviewed By: kstoimenov

Differential Revision: https://reviews.llvm.org/D130218
2022-07-22 13:40:16 -07:00
Julian Lettner 2f46983981 [Sanitizer][Darwin] Factor out code for GCD worker registration
This is a NFC change to factor out GCD worker thread registration via
the pthread introspection hook.

In a follow-up change we also want to register GCD workers for ASan to
make sure threads are registered before we attempt to print reports on
them.

rdar://93276353

Differential Revision: https://reviews.llvm.org/D126351
2022-07-22 13:29:28 -07:00
Dmitry Vyukov b988d8ddc2 tsan: remove unnecessary brackets
Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D130236
2022-07-21 12:11:44 +02:00
Rainer Orth 3776db9a4f [sanitizer_common] Support Solaris < 11.4 in GetStaticTlsBoundary
This patch, on top of D120048 <https://reviews.llvm.org/D120048>, supports
GetTls on Solaris 11.3 and Illumos that lack `dlpi_tls_modid`.  It's the
same method originally used in D91605 <https://reviews.llvm.org/D91605>,
but integrated into `GetStaticTlsBoundary`.

Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.

Differential Revision: https://reviews.llvm.org/D120059
2022-07-21 09:18:10 +02:00
Ian Anderson 28800c2e18 [sanitizer] Use consistent checks for XDR
sanitizer_platform_limits_posix.h defines `__sanitizer_XDR ` if `SANITIZER_LINUX && !SANITIZER_ANDROID`, but sanitizer_platform_limits_posix.cpp tries to check it if `HAVE_RPC_XDR_H`. This coincidentally works because macOS has a broken <rpc/xdr.h> which causes `HAVE_RPC_XDR_H` to be 0, but if <rpc/xdr.h> is fixed then clang fails to compile on macOS. Restore the platform checks so that <rpc/xdr.h> can be fixed on macOS.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D130060
2022-07-20 22:28:07 -07:00
Xi Ruoyao bba1f26f2e Port address sanitizer to LoongArch
Depends on D129371.

It survived all GCC ASan tests.

Changes are trivial and mostly "borrowed" RISC-V logics, except that a different SHADOW_OFFSET is used.

Reviewed By: SixWeining, MaskRay, XiaodongLoong

Differential Revision: https://reviews.llvm.org/D129418
2022-07-21 11:32:21 +08:00
Vitaly Buka 82995e0e82 [NFC][asan] Clang-format a code 2022-07-20 18:57:37 -07:00
Vitaly Buka e8554402b3 [NFC][memprof] Remove unused code 2022-07-20 18:50:45 -07:00
Vitaly Buka 26a7ee3d54 [NFC][asan] Use RoundDownTo 2022-07-20 18:50:44 -07:00
Xi Ruoyao dbec35ccf8 [sanitizer] Port sanitizer_common to LoongArch
Initial libsanitizer support for LoongArch. It survived all GCC UBSan tests.

Major changes:

1. LoongArch port of Linux kernel only supports `statx` for `stat` and its families.  So we need to add `statx_to_stat` and use it for `stat`-like libcalls.  The logic is "borrowed" from Glibc.
2. `sanitizer_syscall_linux_loongarch64.inc` is mostly duplicated from RISC-V port, as the syscall interface is almost same.

Reviewed By: SixWeining, MaskRay, XiaodongLoong, vitalybuka

Differential Revision: https://reviews.llvm.org/D129371
2022-07-20 00:58:40 -07:00
Vitaly Buka 868e1ee1d0 Revert "[libasan] Remove 4Mb stack limit for swapcontext unpoisoning"
This patches exposed existing incorectness of swapcontext imlementation.
swapcontext does not set oucp->uc_stack. Unpoisoning works if ucp is
from makecontext, but may try to use garbage pointers if it's from
previos swapcontext or from getcontext. Existing limit reduces
probability of garbage pointers are used.

I restore behavour which we had for years, and will look to improve
swapcontext support.

This reverts commit d0751c9725.
2022-07-19 21:40:19 -07:00
Andrew Turner 1b2fa907d7 Add the FreeBSD AArch64 memory layout
Use the FreeBSD AArch64 memory layout values when building for it.
These are based on the x86_64 values, scaled to take into account the
larger address space on AArch64.

Reviewed by: vitalybuka

Differential Revision: https://reviews.llvm.org/D125758
2022-07-19 09:58:04 -04:00
Dmitry Vyukov 6d1f86095d tsan: optimize DenseSlabAlloc
If lots of threads do lots of malloc/free and they overflow
per-pthread DenseSlabAlloc cache, it causes lots of contention:

  31.97%  race.old  race.old            [.] __sanitizer::StaticSpinMutex::LockSlow
  17.61%  race.old  race.old            [.] __tsan_read4
  10.77%  race.old  race.old            [.] __tsan::SlotLock

Optimize DenseSlabAlloc to use a lock-free stack of batches of nodes.
This way we don't take any locks in steady state at all and do only
1 push/pop per Refill/Drain.

Effect on the added benchmark:

$ TIME="%e %U %S %M" time ./test.old 36 5 2000000
34.51 978.22 175.67 5833592
32.53 891.73 167.03 5790036
36.17 1005.54 201.24 5802828
36.94 1004.76 226.58 5803188

$ TIME="%e %U %S %M" time ./test.new 36 5 2000000
26.44 720.99 13.45 5750704
25.92 721.98 13.58 5767764
26.33 725.15 13.41 5777936
25.93 713.49 13.41 5791796

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D130002
2022-07-19 15:42:57 +02:00
serge-sans-paille eb0e3319bf [sanitizer] Don't call dlerror() after swift_demangle lookup through dlsym
Because the call to `dlerror()` may actually want to print something, which turns into a deadlock
as showcased in #49223.

Instead rely on further call to dlsym to clear `dlerror` internal state if they
need to check the return status.

Differential Revision: https://reviews.llvm.org/D128992
2022-07-19 09:07:30 +02:00
Xi Ruoyao 36b52c38aa [sanitizer] Compare against the alignment of the latter range trying to find consecutive TLS blocks in GetStaticTlsBoundary
On a mips64el-linux-gnu system, the dynamic linker arranges TLS blocks
like:

    [0] 0xfff7fe9680..0xfff7fe9684, align = 0x4
    [1] 0xfff7fe9688..0xfff7fe96a8, align = 0x8
    [2] 0xfff7fe96c0..0xfff7fe9e60, align = 0x40
    [3] 0xfff7fe9e60..0xfff7fe9ef8, align = 0x8

Note that the dynamic linker can only put [1] at 0xfff7fe9688, not
0xfff7fe9684 or it will be misaligned.  But we were comparing the
distance between two blocks with the alignment of the previous range,
causing GetStaticTlsBoundary fail to merge the consecutive blocks.

Compare against the alignment of the latter range to fix the issue.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D129112
2022-07-17 00:45:15 -07:00
Rainer Orth 74f6672e59 [sanitizer_common] Several Solaris procmaps fixes
Since the introduction of GoogleTest sharding in D122251
<https://reviews.llvm.org/D122251>, some of the Solaris sanitizer tests
have been running extremly long (up to an hour) while they took mere
seconds before.  Initial investigation suggests that massive lock
contention in Solaris procfs is involved here.

However, there's an easy way to somewhat reduce the impact: while the
current `ReadProcMaps` uses `ReadFileToBuffer` to read `/proc/self/xmap`,
that function primarily caters to Linux procfs reporting file sizes of 0
while the size on Solaris is accurate.  This patch makes use of that,
reducing the number of syscalls involved and reducing the runtime of
affected tests by a factor of 4.

Besides, it handles shared mappings and doesn't call `readlink` for unnamed
map entries.

Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`.

Differential Revision: https://reviews.llvm.org/D129837
2022-07-16 06:59:00 +02:00
Julian Lettner 32a425ec0c [Sanitizer][Darwin][NFC] Small SANITIZER_APPLE cleanup
We introduced `SANITIZER_APPLE` here: https://reviews.llvm.org/D126263
2022-07-15 16:31:35 -07:00
Leonard Grey 1231a2cec0 [lsan][Darwin][nfc] Fix thread vector size
The reserve constructor was removed in 44f55509d7
but this one was missed. As a result, we attempt to iterate through 1024 threads
each time, most of which are 0.

Differential Revision: https://reviews.llvm.org/D129897
2022-07-15 17:34:29 -04:00
Leonard Grey b15cf06fb3 [lsan][nfc] Add missing newline to VReport 2022-07-15 15:44:23 -04:00
Petr Hosek cae5462a2c [compiler-rt][CMake] Set unwinder for MSan unittests
This addresses an issue introduced by 6699f55488.
2022-07-15 08:11:59 +00:00
Petr Hosek 6699f55488 [compiler-rt][CMake] Set --unwindlib=none when using LLVM libunwind
We already link libunwind explicitly so avoid trying to link toolchain's
default libunwind which may be missing. This matches what we already do
for libcxx and libcxxabi.

Differential Revision: https://reviews.llvm.org/D129472
2022-07-15 07:25:38 +00:00
Kostya Serebryany ef0081d608 [SanitizerCoverage] add weak definitions for the load/store callbacks.
Add weak definitions for the load/store callbacks.

This matches the weak definitions for all other SanitizerCoverage
callbacks.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D129801
2022-07-14 20:26:41 -07:00
Vitaly Buka bb4d974135 [NFC] Clang-format D129645 2022-07-14 10:27:04 -07:00
Dmitry Vyukov ab02680b5a tsan: fix a bug in trace part switching
Callers of TraceSwitchPart expect that TraceAcquire will always succeed
after the call. It's possible that TryTraceFunc/TraceMutexLock in TraceSwitchPart
that restore the current stack/mutexset filled the trace part exactly up
to the TracePart::kAlignment gap and the next TraceAcquire won't succeed.
Skip the alignment gap after writing initial stack/mutexset to avoid that.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D129777
2022-07-14 17:49:00 +02:00
Alexander Potapenko b191056f44 [compiler-rt][hwasan] Support for new Intel LAM API
New version of Intel LAM patches
(https://lore.kernel.org/linux-mm/20220712231328.5294-1-kirill.shutemov@linux.intel.com/)
uses a different interface based on arch_prctl():
 - arch_prctl(ARCH_GET_UNTAG_MASK, &mask) returns the current mask for
   untagging the pointers. We use it to detect kernel LAM support.
 - arch_prctl(ARCH_ENABLE_TAGGED_ADDR, nr_bits) enables pointer tagging
   for the current process.

Because __NR_arch_prctl is defined in different headers, and no other
platforms need it at the moment, we only declare internal_arch_prctl()
on x86_64.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D129645
2022-07-13 19:11:13 -07:00
Leonard Chan 21f72c05c4 [hwasan] Add __hwasan_add_frame_record to the hwasan interface
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_add_frame_record)

Differential Revision: https://reviews.llvm.org/D128387
2022-07-13 15:15:15 -07:00
Leonard Chan d843d5c8e6 Revert "[hwasan] Add __hwasan_record_frame_record to the hwasan interface"
This reverts commit 4956620387.

This broke a sanitizer builder: https://lab.llvm.org/buildbot/#/builders/77/builds/19597
2022-07-13 15:06:07 -07:00
leonardchan 4956620387 [hwasan] Add __hwasan_record_frame_record to the hwasan interface
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
2022-07-14 05:07:11 +08:00
Mitch Phillips 81c48436bb [~NFC] Fix printf() type punning warning in asan_globals.cpp 2022-07-12 10:48:43 -07:00
Mariusz Borsa af0a26b476 [Sanitizers][Darwin] Remove SANITIZER_MAC
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
2022-07-12 09:11:17 -07:00
Fangrui Song 9cf13067cb [sanitizer] Remove #include <linux/fs.h> to resolve fsconfig_command/mount_attr conflict with glibc 2.36
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
2022-07-11 12:53:35 -07:00
Fangrui Song d2ce7e824d Revert "[sanitizer] Remove #include <linux/fs.h> to resolve fsconfig_command/mount_attr conflict with glibc 2.36"
This reverts commit b379129c4b.

Breaks Android build. Android sys/mount.h doesn't define macros like BLKBSZGET.
2022-07-11 12:53:34 -07:00
Fangrui Song b379129c4b [sanitizer] Remove #include <linux/fs.h> to resolve fsconfig_command/mount_attr conflict with glibc 2.36
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
2022-07-11 11:38:28 -07:00
Alex Brachet 1039165b96 [scudo][NFC] Clang-format c823cbf699
Ran `git clang-format` but didn't add the changed file...
2022-07-11 17:41:37 +00:00
Alex Brachet c823cbf699 [scudo][Fuchsia] Don't assume MapPlatformData::Vmar is valid
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
2022-07-11 17:39:44 +00:00
Ivan Trofimov d0751c9725 [libasan] Remove 4Mb stack limit for swapcontext unpoisoning
Reviewed By: vitalybuka, eugenis

Differential Revision: https://reviews.llvm.org/D129219
2022-07-11 10:32:43 -07:00
Dominic Chen ec9907fbf6 [scudo] Satisfy -Wstrict-prototypes
Differential Revision: https://reviews.llvm.org/D129391
2022-07-11 10:28:38 -07:00
Ivan Trofimov f20a3cbefd [NFC][asan] Clang-format a test
Part of D129219.
2022-07-11 10:12:05 -07:00
Than McIntosh 127e59048c tsan: update Go x86 build rules to back off to sse3
This is a partial revert of https://reviews.llvm.org/D106948, changing
just the Go build rules to remove -msse4.2 and revert back to -msse3,
so as to preserve support for older x86 machines. More details at
https://github.com/golang/go/issues/53743.

Reviewed By: dvyukov

Differential Revision: https://reviews.llvm.org/D129482
2022-07-11 12:41:24 -04:00
Petr Hosek fb89c41269 [CMake] Set the common link flags for memprof tests
This was missed in ba007f20bb by mistake.
2022-07-09 09:03:33 +00:00
Petr Hosek ba007f20bb [CMake] Use explicit header path when using in-tree libc++ for tests
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
2022-07-09 06:14:29 +00:00
Petr Hosek 99cc28b705 Revert "[CMake] Use explicit header path when using in-tree libc++ for tests"
This reverts commit 61b410cb8b as this
appears to have broken some sanitizer tests.
2022-07-09 04:27:16 +00:00
Petr Hosek 61b410cb8b [CMake] Use explicit header path when using in-tree libc++ for tests
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
2022-07-09 03:18:46 +00:00
Petr Hosek df90d22704 [CMake] Option to select C++ library for runtimes that use it
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
2022-07-08 22:10:24 +00:00
Julian Lettner ca50840b5b [Sanitizer][Darwin] Cleanup MaybeReexec() function and usage
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
2022-07-08 14:31:42 -07:00
Leonard Chan 474c873148 Revert "[llvm] cmake config groundwork to have ZSTD in LLVM"
This reverts commit f07caf20b9 which seems to break upstream https://lab.llvm.org/buildbot/#/builders/109/builds/42253.
2022-07-08 13:48:05 -07:00
Cole Kissane f07caf20b9 [llvm] cmake config groundwork to have ZSTD in LLVM
- added `FindZSTD.cmake`
- added a CMake option `LLVM_ENABLE_ZSTD` with behavior mirroring that of `LLVM_ENABLE_ZLIB`
- likewise added have_zstd to compiler-rt/test/lit.common.cfg.py, clang-tools-extra/clangd/test/lit.cfg.py, and several lit.site.cfg.py.in files mirroring have_zlib behavior

Reviewed By: leonardchan, MaskRay

Differential Revision: https://reviews.llvm.org/D128465
2022-07-08 11:46:52 -07:00
Julian Lettner 7789c9afc1 Revert "[Sanitizer][Darwin] Cleanup MaybeReexec() function and usage"
Many tests for the `UBSan-Standalone-iossim-x86_64` fail with this.
Reverting so I can investigate.

This reverts commit 0a9667b0f5.
2022-07-07 17:27:10 -07:00
Julian Lettner 0a9667b0f5 [Sanitizer][Darwin] Cleanup MaybeReexec() function and usage
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
2022-07-07 16:39:27 -07:00
Leonard Chan c211041802 [hwasan][fuchsia] Fix features bitmask checking
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
2022-07-07 14:43:00 -07:00
Dominic Chen 5f3818c7df [scudo] Add [[no_unique_address]] attribute to new MapPlatformData variables
Differential Revision: https://reviews.llvm.org/D129237
2022-07-07 13:12:55 -07:00
Dominic Chen ff8c0e6eb5 [scudo] Pass MapPlatformData in more calls
Allow platforms to avoid looking up private data by providing private context

Differential Revision: https://reviews.llvm.org/D129237
2022-07-07 10:43:07 -07:00
theidexisted 85236e6f3b [NFC][sanitizer] Minor change: eliminate loop
Reviewed By: #sanitizers, fmayer, vitalybuka

Differential Revision: https://reviews.llvm.org/D128873
2022-07-07 10:33:08 -07:00
Vitaly Buka ba4435eb62 [msan] Fix dn_comp interceptor after D126851
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
2022-07-07 09:27:44 -07:00
Vitaly Buka 9a04710b57 [NFC][sanitizer] Format dn_expand interceptor 2022-07-06 21:21:17 -07:00
Sunho Kim 30b6c51f51 [ORC][ORC_RT][AArch64] Implement TLS descriptor in ELFNixPlatform.
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
2022-07-06 20:12:22 +09:00
Dimitrije Milosevic 5d8077565e [MIPS] Resolve issues in building ASAN for N32 ABI
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
2022-07-06 12:44:29 +02:00
Julian Lettner 18e4674ea6 [Sanitizer][Darwin] Fix log-path_test.cpp
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
2022-07-05 16:34:55 -07:00
Andi-Bogdan Postelnicu 6e2058e588 [Compiler-RT] Remove FlushViewOfFile call when unmapping gcda files on win32.
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
2022-07-05 13:24:28 +00:00
Vitaly Buka 7788b0c097 [lsan] malloc_usable_size returns 0 for nullptr 2022-07-02 20:16:30 -07:00
Vitaly Buka f2fa4f9759 [sanitizer] Update dn_expand interceptor for glibc 2.34
Symbol changed with 640bbdf71c6f10ac26252ac67a22902e26657bd8
2022-07-01 16:26:58 -07:00
Petr Hosek 291e3a8565 [compiler-rt] Update Fuchsia sanitizer sched_yield
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
2022-07-01 17:25:57 +00:00
Julian Lettner 3abf3df08a [Sanitizer][Darwin] Lookup dyld image header via shared cache
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
2022-06-30 15:45:25 -07:00
Kostya Serebryany 92fb310151 [libFuzzer] Extend the fuzz target intarface to allow -1 return value.
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
2022-06-30 13:21:27 -07:00
Mariusz Borsa 67ced6af3b [Sanitizers] Cleanup handling of stat64/statfs64
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
2022-06-28 15:01:38 -07:00
Matthias Braun a145a32544 build_symbolizer: Set LLVM_DEFAULT_TARGET_TRIPLE in llvm builds
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
2022-06-28 14:49:35 -07:00
Matthias Braun 2030e6496a Avoid ar_to_bc.sh script in symbolizer build; add -ignore-non-bitcode flag to llvm-link
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
2022-06-28 14:49:35 -07:00
Than McIntosh 13fb97d688 tsan: add missing guard for DumpProcessMap call
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
2022-06-27 10:10:45 -04:00
Petr Hosek f3caa98e49 Revert "[CMake][compiler-rt] Clean up the use of libcxx and libcxxabi"
This reverts commit 4164cfa537 since
it broke the clang-x86_64-debian-fast builder:

  https://lab.llvm.org/buildbot/#/builders/109/builds/41339
2022-06-25 03:10:55 +00:00
Petr Hosek 4164cfa537 [CMake][compiler-rt] Clean up the use of libcxx and libcxxabi
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
2022-06-25 02:53:43 +00:00
Petr Hosek 72ec31afad [CMake] Use set rather than list PREPEND
list PREPEND is only supported since CMake 3.15.

Differential Revision: https://reviews.llvm.org/D128548
2022-06-25 02:19:55 +00:00
Petr Hosek 048e6bb46b [CMake][compiler-rt] Treat target cflags as list rather than string
This is need after 30dfe016d4.

Differential Revision: https://reviews.llvm.org/D128548
2022-06-24 22:37:00 +00:00
Petr Hosek 8bee6e52f8 Revert "[CMake][compiler-rt] Clean up the use of libcxx and libcxxabi"
This reverts commit c0d4f2282d which
broke clang-x86_64-debian-fast:

  https://lab.llvm.org/buildbot/#/builders/109/builds/41268
2022-06-24 08:24:45 +00:00
Petr Hosek c0d4f2282d [CMake][compiler-rt] Clean up the use of libcxx and libcxxabi
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
2022-06-24 08:11:37 +00:00
Lang Hames 232bd331cb [ORC-RT] Make the ORC runtime C API public.
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
2022-06-16 19:02:23 -07:00
Fangrui Song 0e182469ee [sanitizer] Delete empty sanitizer_openbsd.cpp after D89759 2022-06-16 16:38:01 -07:00
Mitch Phillips 13e9c1d18e Reland "[ASan] Use debuginfo for symbolization."
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
2022-06-16 13:58:55 -07:00
Kristina Bessonova 5cfbfa035f [sanitizer_common] Fix SanitizerCommon.ChainedOriginDepotStats test
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
2022-06-16 11:59:58 +02:00
Kirill Stoimenov 99796d06db Revert "[ASan] Use debuginfo for symbolization."
This reverts commit f0ab8d90d4.
2022-06-15 23:42:46 +00:00
Mitch Phillips f0ab8d90d4 [ASan] Use debuginfo for symbolization.
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
2022-06-15 15:36:36 -07:00
Benjamin Kramer 8bc0bb9564 Add a conversion from double to bf16
This introduces a new compiler-rt function `__truncdfbf2`.
2022-06-15 12:56:31 +02:00
Benjamin Kramer fb34d531af Promote bf16 to f32 when the target doesn't support it
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
2022-06-15 12:56:31 +02:00
Petr Hosek 7524fe962e [libFuzzer] Use the compiler to link the relocatable object
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
2022-06-15 07:16:40 +00:00
Petr Hosek 18a1fc8459 [CMake][compiler-rt] Provide a dedicated option for LLVM unwinder
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
2022-06-14 17:26:25 +00:00
Mariusz Borsa a4bf361454 Revert "[Sanitizers] Cleanup handling of stat64/statfs64"
This reverts commit 6d890a0fb8.
2022-06-10 10:56:26 -07:00
Peter S. Housel 2be5abb7e9 [ORC][ORC_RT] Handle ELF .init_array with non-default priority
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
2022-06-09 22:47:58 -07:00
Peter S. Housel 1aa71f8679 [ORC][ORC_RT] Integrate ORC platforms with LLJIT and lli
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
2022-06-09 22:47:58 -07:00
Mariusz Borsa 6d890a0fb8 [Sanitizers] Cleanup handling of stat64/statfs64
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
2022-06-09 12:51:34 -07:00
David Carlier a4c97e1937 [Sanitizers] prctl interception update for the PR_SET_VMA option case.
Supports on Android but also from Linux 5.17

Reviewers: vitalybuka, eugenis

Reviewed-By: vitalybuka

Differential Revision: https://reviews.llvm.org/D127326
2022-06-09 06:07:26 +01:00
Andrew Turner ccae01cbce [compiler-rt] Fix Mmap on FreeBSD AArch64
On FreeBSD AArch64 safestack needs to use __syscall to handle 64 bit arguments

Reviewed by: MaskRay, vitalybuka

Differential Revision: https://reviews.llvm.org/D125901
2022-06-08 17:22:33 -04:00
Andrew Turner ad3faddaa6 [compiler-rt] Fix the longjmp sp slot on FreeBSD AArch64
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
2022-06-08 17:22:27 -04:00
Andrew Turner b3c1442c6c [compiler-rt] Add the FreeBSD AArch64 shadow offset
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
2022-06-08 17:22:16 -04:00
Andrew Turner 9496e39b4a [compiler-rt] Add the common FreeBSD AArch64 support
Reviewed by: vitalybuka

Differential Revision: https://reviews.llvm.org/D125756
2022-06-08 17:22:01 -04:00
Leonard Chan 060907dd00 Revert "Reland "[NFC][compiler-rt][asan] Unify asan and lsan allocator settings""
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.
2022-06-08 11:56:33 -07:00
Leonard Chan 033af5a537 [compiler-rt][hwasan] Check address tagging mode in InitializeOsSupport on Fuchsia
Differential Revision: https://reviews.llvm.org/D127262
2022-06-08 11:34:50 -07:00
Nikita Popov 38ad963cc9 [sanitizer] Fix shift UB in LEB128 test
If u64 and uptr have the same size, then this will perform a shift
by the bitwidth, which is UB. We only need this code if uptr is
smaller than u64.
2022-06-08 14:21:25 +02:00
David CARLIER c06ef17359 [Sanitizers] intercept FreeBSD procctl
Reviewers: vitalybuka, emaster

Reviewed-By: viatelybuka

Differential Revision: https://reviews.llvm.org/D127069
2022-06-08 08:55:10 +01:00
Leonard Chan b37d84aa8d Reland "[NFC][compiler-rt][asan] Unify asan and lsan allocator settings"
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.
2022-06-07 18:09:48 -07:00
Kevin Athey 67069e1980 [MSAN] exclude android from pthread_getaffinity_np interceptor
Depends on https://reviews.llvm.org/D127185.

Differential Revision: https://reviews.llvm.org/D127264
2022-06-07 17:53:32 -07:00
Leonard Chan 13eb4fc3ce Revert "[NFC][compiler-rt][asan] Unify asan and lsan allocator settings"
This reverts commit dd045ddffc.

This broke the sanitizer-windows builder at https://lab.llvm.org/buildbot/#/builders/127/builds/30751.
2022-06-07 17:34:29 -07:00
Leonard Chan 4b15e665f8 [compiler-rt][lsan] Choose lsan allocator via SANITIZER_CAN_USE_ALLOCATOR64
Rather than checking a bunch of individual platforms.

Differential Revision: https://reviews.llvm.org/D126825
2022-06-07 17:23:38 -07:00
Leonard Chan dd045ddffc [NFC][compiler-rt][asan] Unify asan and lsan allocator settings
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
2022-06-07 17:21:19 -07:00
Leonard Chan e1d84c421d [compiler-rt][sanitizer] Have all OOM-related error messages start with the same format
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
2022-06-07 16:46:01 -07:00
Lang Hames 5368c685d9 [ORC-RT] Remove a stale comment. 2022-06-07 16:42:37 -07:00
Kevin Athey 828c94c0f6 [MSAN] Add interceptor for pthread_getaffinity_np.
Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D127185
2022-06-07 16:27:44 -07:00
Paul Kirth acfeb1a6c2 [compiler-rt] Avoid truncating Symbolizer output
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
2022-06-07 21:50:39 +00:00
Arthur Eubanks f9ac557567 [NFC] Properly suppress unused argument warning in __isOSVersionAtLeast()
Casting to non-void causes
  expression result unused [-Wunused-value]
2022-06-06 19:41:26 -07:00
Martin Storsjö 03c19f41a2 [builtins] Check __SEH__, when checking if ARM EHABI is implied
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
2022-06-06 23:23:08 +03:00
Kevin Athey 1a729bce86 [MSAN] add dn_expand intercept.
This interceptor only addresses writes to inputs.  Reads of inputs are not checked.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D126851
2022-06-03 09:49:42 -07:00
Andrew Browne 31d12df3b9 [DFSan] Remove deprecated flag from build-libc-list.py
Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D126429
2022-06-01 11:00:13 -07:00
Fangrui Song 241e645036 ar_to_bc.sh: Ignore non-bitcode files in archives
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
2022-06-01 10:28:14 -07:00
Nico Weber be223eb541 sanitizers: Do not include crypt.h if SANITIZER_INTERCEPT_CRYPT_R is undef
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
2022-06-01 13:27:06 -04:00
Brooks Davis 18efa420da compiler-rt: Allow build without __c11_atomic_fetch_nand
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
2022-06-01 12:58:30 -04:00
Andrew Ng e06a81d810 [LSAN] Fix up LSAN weak symbols for Windows
Differential Revision: https://reviews.llvm.org/D126703
2022-06-01 10:18:51 +01:00
Mariusz Borsa e2adffc39c [Sanitizers][Darwin] Deprecate SANITIZER_MAC - fail compilation if encountered
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
2022-05-31 18:08:59 -07:00
Andrew Browne 15d5db276c [DFSan] build-libc-list.py no longer provides a list of default files.
Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D126430
2022-05-31 11:25:56 -07:00
Alex Brachet 7df55e5ed7 [scudo] Ensure pointer is not null
Differential revision: https://reviews.llvm.org/D126499
2022-05-31 17:16:49 +00:00
Alex Brachet 35a032eaf4 [InstrProf] Stop exporting lprofDirMode
This symbol should not be exposed and doesn't need to be.

Differential revision: https://reviews.llvm.org/D126548
2022-05-31 17:13:00 +00:00
Keno Fischer 167fb106d2 compiler-rt/cpu_model: Ensure constructor priority is set and align with GCC
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
2022-05-30 20:31:49 +00:00
Pierre Gousseau 4278b7e16a [sanitizers] Fixes strndup API behaviour when intercepted by sanitizers
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
2022-05-30 17:00:10 +01:00
Roland McGrath a27b9139ab [scudo] Clean up Zircon header file uses
Make fuchsia.h and fuchsia.cpp each include what they use.
2022-05-27 21:39:03 -07:00
John Paul Adrian Glaubitz a1ec3c5a88 [scudo] Link against libatomic on all MIPS targets
Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D126418
2022-05-26 00:00:16 -07:00
Andrew Browne b2b0322a81 [DFSan] Add option to specify individual library files, and an option to exit with an error code if any library file was not found.
Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D126336
2022-05-24 16:15:46 -07:00
Mariusz Borsa 8246b2e156 [Sanitizers][Darwin] Replace SANITIZER_MAC with SANITIZER_APPLE in source files
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
2022-05-24 12:59:27 -07:00
Leonard Chan 6edbdf80ca Revert "[compiler-rt][scudo] Add missing preprocessor token" and "[compiler-rt][scudo] Simplify TBI checks"
This reverts commit 676eaa2ca9
and f6038cdca0 since builders are still
broken.
2022-05-24 11:30:31 -07:00
Leonard Chan 676eaa2ca9 [compiler-rt][scudo] Add missing preprocessor token
This should fix build errors seen on bots like
https://lab.llvm.org/buildbot/#/builders/57/builds/18263.
2022-05-24 11:12:30 -07:00
Leonard Chan f6038cdca0 [compiler-rt][scudo] Simplify TBI checks
Differential Revision: https://reviews.llvm.org/D111080
2022-05-24 10:53:09 -07:00