| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fixes warnings (or errors, if someone injects -Werror in their build system,
which happens in fact with some folks vendoring LLVM too) with Clang 16:
```
+/var/tmp/portage.notmp/portage/sys-devel/llvm-15.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
-/var/tmp/portage.notmp/portage/sys-devel/llvm-14.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: error: a function declaration without a prototype is
deprecated in all versions of C [-Werror,-Wstrict-prototypes]
int main() {return 0;}
^
void
```
Differential Revision: https://reviews.llvm.org/D137503
(cherry picked from commit 32a2af44e1e882f13d1cc2817f0a8d4d8b375d4d)
|
|
and fix it for 32-bit ports defining sem_init@GLIBC_2.0 (i386, mips32, powerpc32) for glibc>=2.36.
Fix https://github.com/llvm/llvm-project/issues/58079
Reviewed By: mgorny
Differential Revision: https://reviews.llvm.org/D135023
(cherry picked from commit 6f46ff3765dcdc178b9cf52ebd8c03437806798a)
|
|
As described in Issue #54196
<https://github.com/llvm/llvm-project/issues/54196>, the ideas of `clang`
and `compiler-rt` where runtime libs are located with
`-DLLVM_ENABLE_RUNTIMES` can differ. This is the `compiler-rt` side of the
patch I've used to get them in sync for the `amd64-pc-solaris2.11` and
`sparc64-unknown-linux-gnu` release builds.
Tested on `amd64-pc-solaris2.11` and `sparc64-unknown-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D133406
(cherry picked from commit cadc9cdedfef892b00b17658a823e4846a71e3ac)
|
|
Fix the is_binutils_lto_supported() function to handle missing
executables gracefully. Currently, the function does not catch
exceptions from subprocess.Popen() and therefore causes lit to crash
if config.gold_executable does not specify a valid executable:
```
lit: /usr/lib/python3.11/site-packages/lit/TestingConfig.py:136: fatal: unable to parse config file '/tmp/portage/sys-libs/compiler-rt-
15.0.0/work/compiler-rt/test/lit.common.cfg.py', traceback: Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/lit/TestingConfig.py", line 125, in load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
File "/tmp/portage/sys-libs/compiler-rt-15.0.0/work/compiler-rt/test/lit.common.cfg.py", line 561, in <module>
if is_binutils_lto_supported():
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/tmp/portage/sys-libs/compiler-rt-15.0.0/work/compiler-rt/test/lit.common.cfg.py", line 543, in is_binutils_lto_supported
ld_cmd = subprocess.Popen([exe, '--help'], stdout=subprocess.PIPE, env={'LANG': 'C'})
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/subprocess.py", line 1022, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.11/subprocess.py", line 1899, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'GOLD_EXECUTABLE-NOTFOUND'
```
Differential Revision: https://reviews.llvm.org/D133358
(cherry picked from commit ea953b9d9a65c202985a79f1f95da115829baef6)
|
|
is available
Differential Revision: https://reviews.llvm.org/D131147
(cherry picked from commit f061cfb31730b72b7d8920bb4a306a1d2ce7f2e4)
|
|
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
(cherry picked from commit 8342ea6eac85bd20c56be0ab71b4ebbccd134c67)
|
|
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 8f24a56a3a9363f353c8da318d97491a6818781d.
Differential Revision: https://reviews.llvm.org/D130988
(cherry picked from commit 542977d43841820614a32823c33415042430e230)
|
|
Fixes https://github.com/llvm/llvm-project/issues/56960
Differential Revision: https://reviews.llvm.org/D131288
(cherry picked from commit 9ec4ddd224f400e2ec309fa513904525c059cc1e)
|
|
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
(cherry picked from commit 0b2d5fd48bc281af89e5e7bfa33a3054b826ed52)
|
|
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
|
|
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
|
|
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
|
|
Extension of D127929
rdar://80997227
Differential Revision: https://reviews.llvm.org/D130499
|
|
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
|
|
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
|
|
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
|
|
Add the MIPS O32 ABI value for the stat struct's size.
Differential Revision: https://reviews.llvm.org/D129749.
|
|
Reviewed By: vitalybuka, eugenis
Differential Revision: https://reviews.llvm.org/D129219
|
|
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
|
|
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
|
|
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
|
|
with links to discourse.
Reviewed By: #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D129675
|
|
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D130236
|
|
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
|
|
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
|
|
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
|
|
|
|
|
|
|
|
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
|
|
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 d0751c9725aab1dad3d86481e13a4628356e7422.
|
|
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
|
|
This re-applies bb939931a1ad, which had been reverted by 09cebfb978de
because it broke Chromium. The issues seen by Chromium should be
addressed by 1d0f79558ca4.
Differential Revision: https://reviews.llvm.org/D128927
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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 bb939931a1adb9a47a2de13c359d6a72aeb277c8.
|
|
|
|
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
|
|
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
|
|
We introduced `SANITIZER_APPLE` here: https://reviews.llvm.org/D126263
|
|
The reserve constructor was removed in 44f55509d75d8c67077810bb6d9f3bedaea05831
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
|
|
|
|
This addresses an issue introduced by 6699f554880087106a02be1675395bf2cc6f46c8.
|
|
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
|
|
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
|
|
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
|
|
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
|
|
|
