Commit Graph

15864 Commits

Author SHA1 Message Date
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
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
Vitaly Buka d1b7d57cab [sanitizer] Deduplicate dn_expand test
Reviewed By: kstoimenov

Differential Revision: https://reviews.llvm.org/D129246
2022-07-07 14:47:35 -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
Vitaly Buka f67fc3acad [sanitizer] Extract check_mem_is_good into header
Reviewed By: kstoimenov

Differential Revision: https://reviews.llvm.org/D129245
2022-07-07 12:06:49 -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