This ensures that the directory layout of the libc++/libc++abi matches
exactly what we would get on a real installation. Currently the build
directory happens to match the install directory layout, but this will
no longer be true in the future.
In PGO continuous mode, we mmap the profile file into shared memory, which
allows multiple processes to be updating the same memory.
The -fprofile-update=atomic option forces the counter increments to be atomic,
but the counter size is always 64-bit (in -m32 and -m64), so in 32-bit mode the
atomic operations are function calls to libatomic.a and these function calls use
locks.
The lock based libatomic.a functions are per-process, so two processes will race
on the same shared memory because each will acquire their own lock.
In LTO builds, some test checks can be optimized away, since the
compiler can
see through the memory accesses after inlining across TUs. This causes
the existing death tests to fail, since the functions are completely
optimized out and things like copying a lambda will no longer occur and
trigger the sanitizer.
To prevent that, we can use an empty inline assembly block to tell the
compiler that memory is modified, and prevent it from doing that.
This is a quick fix for b71c44b9be17dc6295eb733d685b38e797f3c846
"last released" was removed by accident in primary64.h and the update of
"NumReleasesAttempted" was missing.
Original pull request
[here](https://github.com/llvm/llvm-project/pull/108385)
Fixes issue https://github.com/llvm/llvm-project/issues/105960
If a member in a struct is also a struct, accessing a member partway
through this inner struct currently causes a false positive. This is
because when checking aliasing, the access offset is seen as greater
than the starting offset of the inner struct, so the loop continues one
iteration, and believes we are accessing the member after the inner
struct.
The next member's offset is greater than the offset we are looking for,
so when we subtract the next member's offset from what we are looking
for, the offset underflows.
To fix this, we check if the member we think we are accessing has a
greater offset than the offset we are looking for. If so, we take a step
back. We cannot do this in the loop, since the loop does not check the
final member. This means the penultimate member would still cause false
positives.
N3322 makes NULL + 0 well-defined in C, matching the C++ semantics.
Adjust the pointer-overflow sanitizer to no longer report NULL + 0 as a
pointer overflow in any language mode. NULL + nonzero will of course
continue to be reported.
As N3322 is part of
https://www.open-std.org/jtc1/sc22/wg14/www/previous.html, and we never
performed any optimizations based on NULL + 0 being undefined in the
first place, I'm applying this change to all C versions.
Fixes an issue discovered with Nix where codesign is executed but Nix
cannot use codesign without faults. Use `find_program` in CMake to
ensure it is in `$PATH`.
Can be tested on macOS and change your path in such a way that
`codesign` isn't in it.
Related: https://github.com/NixOS/nixpkgs/pull/329058
This patch restores previous behavior. Even when the Compiler ID is set
to AppleClang, we expect Compiler RT Tests to use Clang as the compiler
ID. This impacts various make and lit commands.
Caused by: https://github.com/llvm/llvm-project/pull/117812/files
rdar://141548700
Soft-transition the removal of setting ZXTEST_USE_STREAMABLE_MACROS, by
only setting the macro if not already defined. A future PR will remove
setting the macro entirely in harness.h.
While fetching amounts of bits used to correctly display ubsan value
reinterpret_cast was used, however as noted by Jakub Jelínek in
https://github.com/llvm/llvm-project/pull/96240 discussion it might
cause issues due to potentially unaligned memory access. The patch
addresses this problem.
Co-authored-by: Vladislav Aranov <vladislav.aranov@ericsson.com>
Our platform has some constraints that allow us to make assumptions that
aren't generally applicable to other platforms. We keep an entirely separate
.s file for the routines.
This compile time test uses inline asm with `.arch` directives to set
the target feature. It is however broken and always fails, since each
`asm()` construct in LLVM sets up a new AsmParser, and therefore the
`.arch` directive has no effect on later `asm()` contents. To fix this
we need to use a single inline `asm()` call with the entire code chunk
to emit contained inside.
The gcov version is set to 11.1 (compatible with gcov 9) even if
`-Xclang -coverage-version=` specified version is less than 11.1.
Therefore, we can drop producer support for version < 11.1.
This patch disables the `noasan-strcmp.test` for AArch64 Linux as it
consistently fails on the buildbot machine while passing on other
AArch64 Linux systems.
We have seen similar issues on noasan-strncmp.test in past which had
random failures on certain machines/environments.
Following buildbot is failing in both check stage1 and stage2:
https://lab.llvm.org/buildbot/#/builders/121/builds/711
TYSan CMake build follows patterns used by other sanitizers, but there's
also a number of issues, like referring to undefined variables, which
breaks the build in some cases (such as cross-compiling). This change
addresses the issues.
Based on #115987, with the introduction of `REQUIRES: continuous-mode`.
Also Linux assumes `runtime_reloc`.
FIXME: image-with-no-counters.c is still excluded.
Linking this runtime requires C++ ABI, which breaks -nostdlib++ builds.
However, UBSAN C++ runtime is only needed for CFI and VPTR checks.
Unblocks #120370.
When ntdll was added to the list of of "interesting DLLs" list (in
d58230b9dcb3b312a2da8f874daa0cc8dc27da9b), the intention was not to
intercept the "mini CRT" functions it exports. OverrideFunction would
only intercept the *first* function it found when searching the list of
DLLs, and ntdll was put last in that list.
However, after 42cdfbcf3e92466754c175cb0e1e237e9f66749e,
OverrideFunction intercepts *all* matching functions in those DLLs. As
a side-effect, the runtime would now intercept functions like memset
etc. also in ntdll.
This causes a problem when ntdll-internal functions like
RtlDispatchException call the intercepted memset, which tries to
inspect uncommitted shadow memory, raising an exception, and getting
stuck in that loop until the stack overflows.
Since we never intended to intercept ntdll's memset etc., the simplest
fix seems to be to actively ignore ntdll when intercepting those
functions.
Fixes#114793
