D14468 added these dummy sections. This patch adds `__attribute__((used))` so
that when compiled by GCC>=11 or (expected, D96838) Clang>=13 on some ELF platforms,
these sections will get SHF_GNU_RETAIN to make sure they will not be discarded
by ld --gc-sections.
We are trying to get rid of LLD's "__start_/__stop_ references retain C identifier name sections" rule.
If LLD drops the rule in the future (we will retain compatibility for `__llvm_prf_*` for a while),
`__llvm_prf_*` will need to have the SHF_GNU_RETAIN flag, otherwise:
```
// __llvm_prf_cnts/__llvm_prf_data usually exist, but {names,vnds} may not exist.
// Such diagnostics will happen with {cnts,data} as well if no input object file is instrumented.
% clang++ -fprofile-generate a.cc -fuse-ld=lld -Wl,--gc-sections
ld.lld: error: undefined hidden symbol: __start___llvm_prf_names
>>> referenced by InstrProfilingPlatformLinux.c
>>> InstrProfilingPlatformLinux.c.o:(__llvm_profile_begin_names) in archive /tmp/RelA/lib/clang/13.0.0/lib/linux/libclang_rt.profile-x86_64.a
...
```
Differential Revision: https://reviews.llvm.org/D96902
During unit tests, it was observed that crafting an artificially small DSO could cause OOB memory to be accessed. This change fixes that (but again, the affected DSOs are unlikely to ever occur outside unit tests).
Reviewed By: morehouse, charco
Differential Revision: https://reviews.llvm.org/D94507
If tsan runtime will try to allocate something during exit handling,
the allocation will fail because there is no VA whatsoever.
It's observed to fail with the following error in some cases:
failed to allocate 0x1000 (4096) bytes of DTLS_NextBlock.
So terminate the process immediately.
Reviewed-in: https://reviews.llvm.org/D96874
This test was found to fail for some of our downstream builds, on
computers where python was not on the default $PATH. Therefore
add a %python substitution to use sys.executable, based on similar
solutions for python calls in tests elsewhere in LLVM.
Differential Revision: https://reviews.llvm.org/D96799
This fixes the weak_hooks.cpp test on FreeBSD. Since this feature appears
to be supported on almost all platforms, it might also make sense to turn
it into an opt-out list instead of being opt-in.
Reviewed By: krytarowski
Differential Revision: https://reviews.llvm.org/D96255
When compiling with ccache, compiler commands get split into smaller steps
and clang's default -Wunused-command-line-argument complains about unused
include directory arguments. In combination -Werror, compilation aborts.
This patch passes the CMAKE_C_FLAGS into the build script. Configuring with
-DCMAKE_C_FLAGS=-Wno-unused-command-line-argument allows successful testing.
Differential Revision: https://reviews.llvm.org/D96762
If an app mmaps lots of memory, a user mmap may end up
in the tsan region for traces. Shadow for this range
overlaps with shadow for other user regions.
This causes havok: from false positives to crashes.
Don't leave unmapped holes in the traces region.
Reviewed-in: https://reviews.llvm.org/D96697
This change adds additional unit tests for fuzzer::Merger::Parse and fuzzer::Merger::Merge in anticipation of additional changes to the merge control file format to support cross-process fuzzing.
It modifies the parameter handling of Merge slightly in order to make NewFeatures and NewCov consistent with NewFiles; namely, Merge *replaces* the contents of these output parameters rather than accumulating them (thereby fixing a buggy return value).
This is change 1 of (at least) 18 for cross-process fuzzing support.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D94506
Not sure what the issue is, but it might be because the test copies
llvm-symbolizer to a different directory, and it can't find libc++.
Try to add some REQUIRES that we use in other tests where we copy
llvm tools out of their original directories.
Windows' memory unmapping has to be explicit, there is no madvise.
Similarly, re-mapping memory has to be explicit as well. This patch
implements a basic method for remapping memory which was previously
returned to the OS on Windows.
Patch by Matthew G. McGovern and Jordyn Puryear
As discussed, these tests are compiled with optimization to mimic real
sanitizer usage [1].
Let's mark relevant functions with `noinline` so we can continue to
check against the stack traces in the report.
[1] https://reviews.llvm.org/D96198
This reverts commit 04af72c5423eb5ff7c0deba2d08cb46d583bb9d4.
Differential Revision: https://reviews.llvm.org/D96357
This is a part of https://reviews.llvm.org/D95835.
The design is based on MSan origin chains.
An 4-byte origin is a hash of an origin chain. An origin chain is a
pair of a stack hash id and a hash to its previous origin chain. 0 means
no previous origin chains exist. We limit the length of a chain to be
16. With origin_history_size = 0, the limit is removed.
The change does not have any test cases yet. The following change
will be adding test cases when the APIs are used.
Reviewed-by: morehouse
Differential Revision: https://reviews.llvm.org/D96160
The recent suffix-log-path_test.c checks for a full stacktrace and
since on some arm-linux-gnu configuration the slow unwinder is used
on default (when the compiler emits thumb code as default), it
requires -funwind-tables on tests.
It also seems to fix the issues disable by d025df3c1de.
Reviewed By: ostannard
Differential Revision: https://reviews.llvm.org/D96337
https://reviews.llvm.org/D95835 implements origin tracking for DFSan.
It reuses the chained origin depot of MSan.
This change moves the utility to sanitizer_common to share between
MSan and DFSan.
Reviewed-by: eugenis, morehouse
Differential Revision: https://reviews.llvm.org/D96319
This test started failing after https://reviews.llvm.org/D95849
defaulted --allow-unused-prefixes to false.
Taking a look at the test, I didn't see an obvious need to add
OS-specific check lines for each supported value of %os.
rdar://74207657
These tests use `--check-prefix=CHECK-%os` but then didn't have
a CHECK line for every os.
In most tests, the linux expectations were sufficient (they match
the "wrap_" prefix with .*), so just remove the check-prefix there.
In the places where this didn't easily work, make sure there are
at least CHECK-Windows and CHECK-Darwin lines.
GNU binutils accepts only `.arch_extension memtag` while Clang
accepts either that or `.arch_extension mte` to mean the same thing.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D95996
Adds a new allocation API to GWP-ASan that handles size+alignment
restrictions.
Reviewed By: cryptoad, eugenis
Differential Revision: https://reviews.llvm.org/D94830
The new pass manager was enabled by default [1].
The commit message states the following relevant differences:
* The inliner works slightly differently
* -O1 does some amount of inlining
These tests are affected because they specify `-O1` and then check the
reported stack trace.
[1] https://reviews.llvm.org/D95380
Differential Revision: https://reviews.llvm.org/D96198
This is a part of https://reviews.llvm.org/D95835.
This change is to address two problems
1) When recording stacks in origin tracking, libunwind is not async signal safe. Inside signal callbacks, we need
to use fast unwind. Fast unwind needs threads
2) StackDepot used by origin tracking is not async signal safe, we set a flag per thread inside
a signal callback to prevent from using it.
The thread registration is similar to ASan and MSan.
Related MSan changes are
* 98f5ea0dba
* f653cda269
* 5a7c364343
Some changes in the diff are used in the next diffs
1) The test case pthread.c is not very interesting for now. It will be
extended to test origin tracking later.
2) DFsanThread::InSignalHandler will be used by origin tracking later.
Reviewed-by: morehouse
Differential Revision: https://reviews.llvm.org/D95963
Switch to new logging api added in [[ https://developer.apple.com/documentation/os/os_log_error | macOS 10.12 ]] that is more memory safe and enables us to label the log messages in the future. Falls back to old API if ran on older OS versions.
Commited by Dan Liew on behalf of Emily Shi.
rdar://25181524
Reviewed By: delcypher, yln
Differential Revision: https://reviews.llvm.org/D95977
We want way to set a path to llvm-symbolizer that isn't relative
to the current working directory; this change adds a variable that
expands to the path relative to the current binary.
This approach came from comments in https://reviews.llvm.org/D93070
Differential Revision: https://reviews.llvm.org/D94563
AsanThread::Destroy implementation expected to be called on
child thread.
I missed authors concern regarding this reviewing D95184.
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D95731
C identifier name input sections such as __llvm_prf_* are GC roots so
they cannot be discarded. In LLD, the SHF_LINK_ORDER flag overrides the
C identifier name semantics.
The !associated metadata may be attached to a global object declaration
with a single argument that references another global object, and it
gets lowered to SHF_LINK_ORDER flag. When a function symbol is discarded
by the linker, setting up !associated metadata allows linker to discard
counters, data and values associated with that function symbol.
Note that !associated metadata is only supported by ELF, it does not have
any effect on non-ELF targets.
Differential Revision: https://reviews.llvm.org/D76802
