Commit Graph

15975 Commits

Author SHA1 Message Date
Evgenii Stepanov cf1d9a1fdc [sanitizer] Use C++17 to build the symbolizer. 2022-08-09 15:33:03 -07:00
Vitaly Buka ea42515dad [asan] Faster version of QuickCheckForUnpoisonedRegion
Slightly helps with performance regression after D128146.
2022-08-08 22:07:35 -07:00
Vitaly Buka 03e345b519 [asan] Avoid few branches on memcpy hot path 2022-08-08 19:20:06 -07:00
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
Fangrui Song a12c076f60 [compiler-rt] Use -std=c++17 for standalone build
Follow-up to D130689.

Reviewed By: thieta

Differential Revision: https://reviews.llvm.org/D131382
2022-08-08 12:04:42 -07:00
Wael Yehia af8205d0eb Revert "XFAIL some PGO tests on AIX until the new linker becomes publicly available."
AIX 7.2 TL5 SP4 and AIX 7.3 TL0 SP2 have been released as of now.
The linker in these OS versions recognizes and properly supports
__start_SECNAME and __stop_SECNAME symbols which are needed for PGO.

This reverts commit 93bb2f16e8.
2022-08-08 14:04:29 +00: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
Louis Dionne 49d2071572 [compiler-rt] Don't build builtins beyond macOS 10.7
It's not supported anyways, and now Clang complains about it since
we didn't support -stdlib=libc++ back then.
2022-08-04 16:48:10 -04:00
Blue Gaston 42c15ca630 [TSAN][Darwin] x86_64 specific tests requiring weak symbols
Additional tests requiring weak symbol attribute work around for macOS 12.0

Differential Revision: https://reviews.llvm.org/D131119
2022-08-03 15:51:23 -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
Fangrui Song d884eb2bce [test] Remove -fsanitize-coverage-whitelist= 2022-08-02 10:25:44 -07:00
Roy Sundahl 3879d3edef [tsan][test] Remaining tests requiring weak symbols for dyld64
Differential Revision: https://reviews.llvm.org/D130917
2022-08-01 11:02:43 -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
Blue Gaston cea1b790f6 [TSan][Darwin] Additional TSAN test requiring weak symbol for dyld64
Tests require a weak symbol for dyld weak-def coalescing.

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

Adding additional weak attribute
2022-07-29 11:24:40 -07:00
Luís Marques a0f1304616 [compiler-rt][builtins][RISCV] Set COMPILER_RT_HAS_FLOAT16 for RISC-V compiler-rt tests, fixes test__extendhfsf2
Since D92241, compiler-rt/cmake/builtin-config-ix.cmake automatically tests
the host compiler for support of _Float16 and conditionally defines
COMPILER_RT_HAS_FLOAT16. That defines the macro while the compiler-rt
builtins are being built. To also define it during the compiler-rt test
runs requires whitelisting the architecture in
compiler-rt/test/builtins/CMakeLists.txt, as done in this patch. That seems
brittle. Ideally, we'd move to a solution where the target compiler was
automatically tested as well, but I'm not sure how feasible that is with the
current CMake setup.

For now, this patch whitelists RISC-V, fixing errors in test__extendhfsf2.
Alternate solutions that fix the root issue are welcome, though.

Differential Revision: https://reviews.llvm.org/D129432
2022-07-29 13:27:44 +02:00
Luís Marques 5bc19fe8f6 Revert "[compiler-rt][builtins][RISCV] Set COMPILER_RT_HAS_FLOAT16 for RISC-V compiler-rt tests, fixes test__extendhfsf2"
This reverts commit 55920d9282.
2022-07-29 13:25:53 +02:00
Luís Marques 55920d9282 [compiler-rt][builtins][RISCV] Set COMPILER_RT_HAS_FLOAT16 for RISC-V compiler-rt tests, fixes test__extendhfsf2
Since D92241, compiler-rt/cmake/builtin-config-ix.cmake automatically tests
the host compiler for support of _Float16 and conditionally defines
COMPILER_RT_HAS_FLOAT16. That defines the macro while the compiler-rt
builtins are being built. To also define it during the compiler-rt test
runs requires whitelisting the architecture in
compiler-rt/test/builtins/CMakeLists.txt, as done in this patch. That seems
brittle. Ideally, we'd move to a solution where the target compiler was
automatically tested as well, but I'm not sure how feasible that is with the
current CMake setup.

For now, this patch whitelists RISC-V, fixing errors in test__extendhfsf2.
Alternate solutions that fix the root issue are welcome, though.

Differential Revision: https://reviews.llvm.org/D129432
2022-07-29 13:24:29 +02:00
Rainer Orth 0b2d5fd48b [compiler-rt][Sanitizer] Link sanitizer libs with -latomic on SPARC
When building on Linux/sparc64, the 32-bit `libclang_rt.asan.so`,
`libclang_rt.ubsan_minimal.so`, and `libclang_rt.ubsan_standalone.so`
failed to link with undefined references to 64-bit atomics, which `clang`
cannot inline.  Even D130569 <https://reviews.llvm.org/D130569> didn't help
because those libraries are linked with `-nodefaultlibs`, so dependent
libraries need to be added explicitly.

That's what this patch does.

Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11`.

Differential Revision: https://reviews.llvm.org/D130571
2022-07-27 12:30:18 +02:00
Blue Gaston a89982c40d [Sanitizers][Darwin] Allows '-mtargetos' to used to set minimum deployment target.
Currently, m{platform}-version-min is default flag used to set min deployment target within compilter-rt and sanitizers.
However, clang uses flags -target and -mtargetos for setting target triple and minimum deployment targets.
-mtargetos will be the preferred flag to set min version in the future and the
${platform}-version-min flag will not be used for future platforms.

This change allows darwin platforms to use either ${platform}-min-version or -mtargetos
without breaking lit test flags that allows for overriding the default min value in lit tests
Tests using flags: 'darwin_min_target_with_tls_support', 'min_macos_deployment_target'
will no longer fail if they use mtargetos instead of version-min.

rdar://81028225

Differential Revision: https://reviews.llvm.org/D130542
2022-07-26 11:25:49 -07: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
Shafik Yaghmour aea82d4551 [Clang] Fix how we set the NumPositiveBits on an EnumDecl to cover the case of single enumerator with value zero or an empty enum
Currently in Sema::ActOnEnumBody(...) when calculating NumPositiveBits we miss
the case where there is only a single enumerator with value zero and the case of
an empty enum. In both cases we end up with zero positive bits when in fact we
need one bit to store the value zero.

This PR updates the calculation to account for these cases.

Differential Revision: https://reviews.llvm.org/D130301
2022-07-25 16:01:01 -07:00
Roy Sundahl 1850a7a9ca [asan][test] Additional test requiring weak symbol for dyld64.
Extension of D127929

rdar://80997227

Differential Revision: https://reviews.llvm.org/D130499
2022-07-25 13:56:02 -07: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
Aaron Ballman 7068aa9841 Strengthen -Wint-conversion to default to an error
Clang has traditionally allowed C programs to implicitly convert
integers to pointers and pointers to integers, despite it not being
valid to do so except under special circumstances (like converting the
integer 0, which is the null pointer constant, to a pointer). In C89,
this would result in undefined behavior per 3.3.4, and in C99 this rule
was strengthened to be a constraint violation instead. Constraint
violations are most often handled as an error.

This patch changes the warning to default to an error in all C modes
(it is already an error in C++). This gives us better security posture
by calling out potential programmer mistakes in code but still allows
users who need this behavior to use -Wno-error=int-conversion to retain
the warning behavior, or -Wno-int-conversion to silence the diagnostic
entirely.

Differential Revision: https://reviews.llvm.org/D129881
2022-07-22 15:24:54 -04:00
tlattner 44f81dfba4 Remove references to old mailing lists that have moved to discourse. Replace with links to discourse.
Reviewed By: #libc_abi, ldionne

Differential Revision: https://reviews.llvm.org/D129675
2022-07-22 09:59:03 -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
Kamau Bridgeman 2a408f200c [TSAN] Disable clone_setns test case on PPC64 RHEL 7.9 Targets
The compler-rt test case tsan/Linux/clone_setns.cpp fails on
PowerPC64 RHEL 7.9 targets.
Unshare fails with errno code EINVAL.
It is unclear why this happens specifically on RHEL 7.9 and no other
operating system like Ubuntu 18 or RHEL 8.4 for example.
This patch uses marcos to disable the test case for ppc64 rhel7.9
because there are no XFAIL directives to target rhel 7.9 specifically.

Reviewed By: dvyukov

Differential Revision: https://reviews.llvm.org/D130086
2022-07-19 13:25:21 -05:00
Louis Dionne 7300a651f5 [libc++] Re-apply "Always build c++experimental.a""
This re-applies bb939931a1, which had been reverted by 09cebfb978
because it broke Chromium. The issues seen by Chromium should be
addressed by 1d0f79558c.

Differential Revision: https://reviews.llvm.org/D128927
2022-07-19 10:44:19 -04: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
Ellis Hoag 3580daacf3 [InstrProf] Allow CSIRPGO function entry coverage
The flag `-fcs-profile-generate` for enabling CSIRPGO moves the pass
`pgo-instrumentation` after inlining. Function entry coverage works fine
with this change, so remove the assert. I had originally left this
assert in because I had not tested this at the time.

Reviewed By: davidxl, MaskRay

Differential Revision: https://reviews.llvm.org/D129407
2022-07-18 15:10:11 -07:00
Hans Wennborg 09cebfb978 Revert "[libc++] Always build c++experimental.a"
This caused build failures when building Clang and libc++ together on Mac:

  fatal error: 'experimental/memory_resource' file not found

See the code review for details. Reverting until the problem and how to
solve it is better understood.

(Updates to some test files were not reverted, since they seemed
unrelated and were later updated by 340b48b267b96.)

> This is the first part of a plan to ship experimental features
> by default while guarding them behind a compiler flag to avoid
> users accidentally depending on them. Subsequent patches will
> also encompass incomplete features (such as <format> and <ranges>)
> in that categorization. Basically, the idea is that we always
> build and ship the c++experimental library, however users can't
> use what's in it unless they pass the `-funstable` flag to Clang.
>
> Note that this patch intentionally does not start guarding
> existing <experimental/FOO> content behind the flag, because
> that would merely break users that might be relying on such
> content being in the headers unconditionally. Instead, we
> should start guarding new TSes behind the flag, and get rid
> of the existing TSes we have by shipping their Standard
> counterpart.
>
> Also, this patch must jump through a few hoops like defining
> _LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
> that do not implement -funstable yet.
>
> Differential Revision: https://reviews.llvm.org/D128927

This reverts commit bb939931a1.
2022-07-18 16:57:15 +02:00
Fangrui Song a1b8d9fb75 [test] Change -lowertypetests tests to use -passes= 2022-07-17 21:33:02 -07: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
Petr Hosek 2da550140a [compiler-rt][CMake] Use linker semantics for unwinder and C++ library
Try the shared library first, and if it doesn't exist fallback onto
the static one. When the static library is requested, skip the shared
library.

Differential Revision: https://reviews.llvm.org/D129470
2022-07-14 21:12:36 +00:00
Ellis Hoag af58684f27 [InstrProf] Add options to profile function groups
Add two options, `-fprofile-function-groups=N` and `-fprofile-selected-function-group=i` used to partition functions into `N` groups and only instrument the functions in group `i`. Similar options were added to xray in https://reviews.llvm.org/D87953 and the goal is the same; to reduce instrumented size overhead by spreading the overhead across multiple builds. Raw profiles from different groups can be added like normal using the `llvm-profdata merge` command.

Reviewed By: ianlevesque

Differential Revision: https://reviews.llvm.org/D129594
2022-07-14 11:41:30 -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
Roy Sundahl 0aefc94651 [asan][ubsan][test] Add weak attributes for dyld Mach-O weak-def-coalescing
Apple's dynamic linker won't weak-def_coalesce from a file unless there is
at least one weak symbol in the compilation unit so  local __ubsan_on_report
never has the chance to override the weak one even though the dynamic linker
may see it first. This works around the issue by adding an unused weak symbol.
(Amended: Remove excessive clang-format artifacts)

rdar://95244261

Differential Revision: https://reviews.llvm.org/D127929
2022-07-13 11:46:56 -07: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
Kai Luo 22b8a198cf [AIX][compiler-rt] Fix missing dependency of parent target
`add_dependencies(${LIB_PARENT_TARGET} aix-${libname})` should only happen when `aix-${libname}` is added.

Reviewed By: hubert.reinterpretcast

Differential Revision: https://reviews.llvm.org/D129433
2022-07-11 10:49:39 +08: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
Louis Dionne bb939931a1 [libc++] Always build c++experimental.a
This is the first part of a plan to ship experimental features
by default while guarding them behind a compiler flag to avoid
users accidentally depending on them. Subsequent patches will
also encompass incomplete features (such as <format> and <ranges>)
in that categorization. Basically, the idea is that we always
build and ship the c++experimental library, however users can't
use what's in it unless they pass the `-funstable` flag to Clang.

Note that this patch intentionally does not start guarding
existing <experimental/FOO> content behind the flag, because
that would merely break users that might be relying on such
content being in the headers unconditionally. Instead, we
should start guarding new TSes behind the flag, and get rid
of the existing TSes we have by shipping their Standard
counterpart.

Also, this patch must jump through a few hoops like defining
_LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
that do not implement -funstable yet.

Differential Revision: https://reviews.llvm.org/D128927
2022-07-08 16:58:22 -04: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
Leonard Chan e115604a59 Revert "[llvm] cmake config groundwork to have ZSTD in LLVM"
This reverts commit adf1ffe958 and f07caf20b9
which seem to break upstream https://lab.llvm.org/buildbot/#/builders/109/builds/42253.
2022-07-08 13:46:44 -07:00
Cole Kissane adf1ffe958 [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 12:36:27 -07:00