The asserted order of THREAD_DESTROY and end of main() is not
guaranteed:
```
7: Hello from pthread
8: THREAD_TERMINATE 0x7e8000104000, self: 0x7e8000104000, name: child thread
9: Done.
10: THREAD_DESTROY 0x7e8000104000, self: 0x7e8000104000, name: child thread
```
Resulting in:
```
error: CHECK: expected string not found in input
// CHECK: Done.
```
Remove checking for "Done." (end of main()) to deflake this test.
Alternatively, we could use `CHECK-DAG`.
rdar://94036145
Addresses tests flakes described in
https://github.com/llvm/llvm-project/issues/55460
The test being updated can fail in FileCheck to match when given long
enough stack traces. This can be problematic when file system paths
become long enough to cause the majority of the long function name to
become truncated. We found in our CI that the truncated output would
often fail to match, thereby causing the test to fail when it should not.
Here we change the test to match on sybolizer output that should be more
reliable than matching inside the long function name.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D126102
3bd112c720 fixed the fuzzing test on Linux, which, after
https://reviews.llvm.org/D125933, has one less branch. Turns out, on
Windows, that it still has the extra branch. I'm guessing that's because
exit() isn't known to be noreturn on Windows or something.
Either way, just make the test more tolerant.
https://reviews.llvm.org/D125933 improved some of LLVM's handling of
binary ORs, which meant we have one less conditional branch, because the
'if (Size > 5 && Data[5] == 'R')' and 'if (bits == 63)' branches are now
correctly folded.
Add a set of tests that iterate over possible combinations of
memory orders for lock free stack implementation.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D110552
Thread create/destroy events are not guaranteed to belivered on the
parent thread, e.g., output from a CI job:
```
5: THREAD_CREATE 0x7e8000104000, self: 0x1102ebdc0, name: n/a
6: THREAD_START 0x7e8000104000, self: 0x7e8000104000, name: n/a
7: Hello from pthread
8: THREAD_TERMINATE 0x7e8000104000, self: 0x7e8000104000, name: child thread
9: THREAD_DESTROY 0x7e8000104000, self: 0x7e8000104000, name: child thread
```
Here, THREAD_DESTROY is delivered on the thread being destroyed.
rdar://92679941
This halves the size of LargeTest, dropping time to compile this
file locally from 14s to 5.5s. Hopefully this will also fix the
persistent timeouts in pre-merge checks.
Differential Revision: https://reviews.llvm.org/D124237
Also enable on X86_64.
The directory would change during the test execution. This should not
necessarily prevent us from indexing a directory (a user might
potentially do that if they specify a parent directory of the actual
symbols directory, and change unrelated files).
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D125143
Since D97044, libc++ implements <stdatomic.h>, which is not compatible
with the <atomic> header in C++03 mode. To fix the tests, avoid using
<stdatomic.h> at all, since it is not strictly required.
rdar://92867529
Differential Revision: https://reviews.llvm.org/D125118
This changes the ELFNix platform Orc runtime to use, when available,
the __unw_add_dynamic_eh_frame_section interface provided by libunwind
for registering .eh_frame sections loaded by JITLink. When libunwind
is not being used for unwinding, the ELFNix platform detects this and
defaults to the __register_frame interface provided by libgcc_s.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D114961
The mechanism behind "check-all" is recording params of add_lit_testsuite()
calls in global variables LLVM_LIT_*, and then creating an extra suite with
their union at the end.
This avoids composing the check-* targets directly, which doesn't work well.
We generalize this by allowing multiple families of variables LLVM_{name}_LIT_*:
umbrella_lit_testsuite_begin(check-foo)
... test suites here will be added to LLVM_FOO_LIT_* variables ...
umbrella_lit_testsuite_end(check-foo)
(This also moves some implementation muck out of {llvm,clang}/CMakeLists.txt
This patch also changes check-clang-tools to use be an umbrella test target,
which means the clangd and clang-pseudo tests are included in it, along with the
the other testsuites that already are (like check-clang-extra-clang-tidy).
Differential Revision: https://reviews.llvm.org/D121838
The current darwin abort_on_error test specifically tests for a division
by zero undefined behavior. However arm does not trap by default for this
behavior. x86 signals the abort, which is why the test passes on x86.
This patch updates the test to test for a case where the ubsan runtime
specifically calls Die() to trigger an abort by default.
rdar://92108564
Differential Revision: https://reviews.llvm.org/D124480
An application can use the mere fact of epoll_wait returning an fd
as synchronization with the write on the fd that triggered the notification.
This pattern come up in an internal networking server (b/229276331).
If an fd is added to epoll, setup a link from the fd to the epoll fd
and use it for synchronization as well.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D124518
Fix mismatched-new-delete in asan test unaligned_loads_and_stores.cpp
Reviewed By: vitalybuka, MaskRay
Differential Revision: https://reviews.llvm.org/D124268
By default -fsanitize=address already compiles with this check,
why not use it.
For compatibly it can be disabled with env ASAN_OPTIONS=detect_stack_use_after_return=0.
Reviewed By: eugenis, kda, #sanitizers, hans
Differential Revision: https://reviews.llvm.org/D124057
On systems where the kernel supports the PR_SCHED_CORE
interface, but there is no SMT, the prctl call will set
errno to ENODEV, which currently causes the test to fail.
Fix by accepting ENODEV in addition to EINVAL.
C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never previously
declared. The resulting function would be globally declared as
extern int func(); -- a function without a prototype which accepts zero
or more arguments.
C99 removed support for this questionable feature due to severe
security concerns. However, there was no deprecation period; C89 had
the feature, C99 didn't. So Clang (and GCC) both supported the
functionality as an extension in C99 and later modes.
C2x no longer supports that function signature as it now requires all
functions to have a prototype, and given the known security issues with
the feature, continuing to support it as an extension is not tenable.
This patch changes the diagnostic behavior for the
-Wimplicit-function-declaration warning group depending on the language
mode in effect. We continue to warn by default in C89 mode (due to the
feature being dangerous to use). However, because this feature will not
be supported in C2x mode, we've diagnosed it as being invalid for so
long, the security concerns with the feature, and the trivial
workaround for users (declare the function), we now default the
extension warning to an error in C99-C17 mode. This still gives users
an easy workaround if they are extensively using the extension in those
modes (they can disable the warning or use -Wno-error to downgrade the
error), but the new diagnostic makes it more clear that this feature is
not supported and should be avoided. In C2x mode, we no longer allow an
implicit function to be defined and treat the situation the same as any
other lookup failure.
Differential Revision: https://reviews.llvm.org/D122983
Makes
bin/llvm-lit \
projects/compiler-rt/test/profile/Profile-arm64/instrprof-darwin-dead-strip.c
pass on my machine.
Without this change, ld64 complains that the bitcode was generated by LLVM 15
while the reader is 13.1 -- the version of Xcode on my machine. Looks like the
DYLD_LIBRARY_PATH technique isn't working.
-lto_library was added back in ld64-136, which was in Xcode 4.6, which was
released over 10 years ago. So relying on it should be safe by now.
Differential Revision: https://reviews.llvm.org/D124018
Usually when we generated stacktraces the process is in error state, so
running hooks may crash the process and prevent meaningfull error report.
Symbolizer, unwinder and pthread are potential source of mallocs.
https://b.corp.google.com/issues/228110771
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D123566
Usually when we generated stacktraces the process is in error state, so
running hooks may crash the process and prevent meaningfull error report.
Symbolizer, unwinder and pthread are potential source of mallocs.
https://b.corp.google.com/issues/228110771
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D123566
ubsan_GetStackTrace (from 52b751088b) called by
~ScopeReport leaves top/bottom zeroes in the
`!WillUseFastUnwind(request_fast_unwind)` code path.
When BufferedStackTrace::Unwind falls back to UnwindFast,
`if (stack_top < 4096) return;` will return early, leaving just one frame in the stack trace.
Fix this by always initializing top/bottom like 261d6e05d5.
Reviewed By: eugenis, yln
Differential Revision: https://reviews.llvm.org/D123562
According to the RFC [0], this review contains the compiler-rt parts of large integer divison for _BitInt.
It adds the functions
```
/// Computes the unsigned division of a / b for two large integers
/// composed of n significant words.
/// Writes the quotient to quo and the remainder to rem.
///
/// \param quo The quotient represented by n words. Must be non-null.
/// \param rem The remainder represented by n words. Must be non-null.
/// \param a The dividend represented by n + 1 words. Must be non-null.
/// \param b The divisor represented by n words. Must be non-null.
/// \note The word order is in host endianness.
/// \note Might modify a and b.
/// \note The storage of 'a' needs to hold n + 1 elements because some
/// implementations need extra scratch space in the most significant word.
/// The value of that word is ignored.
COMPILER_RT_ABI void __udivmodei5(su_int *quo, su_int *rem, su_int *a,
su_int *b, unsigned int n);
/// Computes the signed division of a / b.
/// See __udivmodei5 for details.
COMPILER_RT_ABI void __divmodei5(su_int *quo, su_int *rem, su_int *a, su_int *b,
unsigned int words);
```
into builtins.
In addition it introduces a new "bitint" library containing only those new functions,
which is meant as a way to provide those when using libgcc as runtime.
[0] https://discourse.llvm.org/t/rfc-add-support-for-division-of-large-bitint-builtins-selectiondag-globalisel-clang/60329
Differential Revision: https://reviews.llvm.org/D120327
This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.
Differential Revision: https://reviews.llvm.org/D120682
This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.
Differential Revision: https://reviews.llvm.org/D120682
On Darwin, we want to limit the parallelism during test execution for
sanitizer tests that use shadow memory. The reason is explained by this
existing comment:
> Only run up to 3 processes that require shadow memory simultaneously
> on 64-bit Darwin. Using more scales badly and hogs the system due to
> inefficient handling of large mmap'd regions (terabytes) by the
> kernel.
Previously we detected 3 cases:
* on-device: limit to 1 process
* 64-bit: macOS & simulators, limit to 3 processes
* others (32-bit): no limitation
We checked for the 64-bit case like this: `if arch in ['x86_64',
'x86_64h']` which misses macOS running on AS. Additionally, we don't
care about 32-bit anymore, so I've simplified this to 2 cases: on-device
and everything else.
Differential Revision: https://reviews.llvm.org/D122751
Currently, we only print how threads involved in data race are created from their parent threads.
Add a runtime flag 'print_full_thread_history' to print thread creation stacks for the threads involved in the data race and their ancestors up to the main thread.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D122131
For errno spoiling reports we only print the stack
where the signal handler is invoked. And the top
frame is the signal handler function, which is supposed
to give the info for debugging.
But in same cases the top frame can be some common thunk,
which does not give much info. E.g. for Go/cgo it's always
runtime.cgoSigtramp.
Print the signal number.
This is what we can easily gather and it may give at least
some hints regarding the issue.
Reviewed By: melver, vitalybuka
Differential Revision: https://reviews.llvm.org/D121979
-fsanitize-memory-use-after-dtor detects memory access after a
subobject is destroyed but its memory is not yet deallocated.
This is done by poisoning each object memory near the end of its destructor.
Subobjects (members and base classes) do this in their respective
destructors, and the parent class does the same for its members with
trivial destructors.
Inexplicably, base classes with trivial destructors are not handled at
all. This change fixes this oversight by adding the base class poisoning logic
to the parent class destructor.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D119300
After e5822ded56, the call to LargeFunction can be optimized out, as x
is never accessed in main. This is causing the test to fail, because the
out-of-bounds access won't be executed.
Adding an extra read and returning the value should prevent the
optimizer from removing the call.
glibc >= 2.33 uses shared functions for stat family functions.
D111984 added support for non-64 bit variants but they
do not appear to be enough as we have been noticing msan
errors on 64-bit stat variants on Chrome OS.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D121652
If sanitizer cannot determine name of the module it
will use "<unknown module>". Then it can be suppressed
if needed.
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D121674
This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.
Differential Revision: https://reviews.llvm.org/D119918
The false positive fixed by commit f831d6fc80
("tsan: fix false positive during fd close") still happens episodically
on the added more stressful test which does just open/close.
I don't have a coherent explanation as to what exactly happens
but the fix fixes the false positive on this test as well.
The issue may be related to lost writes during asynchronous MADV_DONTNEED.
I've debugged similar unexplainable false positive related to freed and
reused memory and at the time the only possible explanation I found is that
an asynchronous MADV_DONTNEED may lead to lost writes. That's why commit
302ec7b9bc ("tsan: add memory_limit_mb flag") added StopTheWorld around
the memory flush, but unfortunately the commit does not capture these findings.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D121363
follow up to 0a4dec6cc2.
add unsupported for s390 (SEGV)
restore line that s390 complains, so following asserts work.
Differential Revision: https://reviews.llvm.org/D121326
FdClose is a subjet to the same atomicity problem as MemoryRangeFreed
(memory state is not "monotoic" wrt race detection).
So we need to lock the thread slot in FdClose the same way we do
in MemoryRangeFreed.
This fixes the modified stress.cpp test.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D121143
These are failing on our silent bot:
https://lab.llvm.org/staging/#/builders/162/builds/358
$ <run cmd>
main
foo
bar
baz
SanitizerCoverage: ./sanitizer_coverage_trace_pc_guard-dso.cpp.tmp.2122517.sancov: 2 PCs written
SanitizerCoverage: ./sanitizer_coverage_trace_pc_guard-dso.cpp.tmp_2.so.2122517.sancov: 1 PCs written
SanitizerCoverage: ./sanitizer_coverage_trace_pc_guard-dso.cpp.tmp_1.so.2122517.sancov: 1 PCs written
$ <sancov cmd>
ERROR: Coverage points in binary and .sancov file do not match.
Also reproduces if you build for Thumb on v8 hardware.
Doesn't fail when built with Arm only code so I guess the Thumb mode bit
in the PCs might be the issue.
See post-commit discussion on https://reviews.llvm.org/D120305.
This change breaks the clang-ppc64le-rhel buildbot, though
there is suspicion that it's an issue with the bot. The change
also had a larger than expected impact on compile-time and
code-size.
This reverts commit 3c4ed02698
and some followup changes.
This works with glibc crt1.o (its crt1.o is essentially Scrt1.o plus (if static
PIE is supported for the arch) _dl_relocate_static_pie) but looks wacky.
musl crt1.o is not built with an explicit -fno-pic/-fpie/-fpic. If it was built
with a non-default-pie GCC/Clang, the linker might complain about absolute
relocations referencing _init/_fini for the -pie link:
```
ld: error: relocation R_X86_64_32 cannot be used against symbol '_fini'; recompile with -fPIC
>>> defined in obj/crt/crt1.o
>>> referenced by crt1.c
>>> obj/crt/crt1.o:(_start_c)
```
Aligned new does not require size to be a multiple of alignment, so
memalign is the correct choice instead of aligned_alloc.
Fixes false reports for unaligned sizes.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D119161
The stack trace addresses may be odd (normally addresses should be even), but
seems a good compromise when the instruction length (2,4,6) cannot be detected
easily.
Reviewed By: uweigand
Differential Revision: https://reviews.llvm.org/D120432
TLS teardown is currently broken, as we unpoison the shadow a little bit
and to the right of the TLS section, rather than the full TLS section
itself. This currently breaks at -O0, and breaks with some upcoming
globals code that I have.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D120080
Turns out the test was working by accident: we need to ensure
TSan instrumentation is not called from the fork() hook, otherwise the
tool will deadlock. Previously it worked because alloc_free_blocks() got
inlined into __tsan_test_only_on_fork(), but it cannot always be the
case.
Adding __attribute__((disable_sanitizer_instrumentation)) will prevent
TSan from instrumenting alloc_free_blocks().
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D120050
Third attempt to fix a bot failure from
634da7a1c6 on an Android bot:
https://lab.llvm.org/buildbot#builders/77/builds/14339
My last attempt used an approach from another test where chmod was not
working of using a bad character in the path name. But it looks like
this trick only works on Windows.
Instead, restore the original version of this test before my change at
634da7a1c6 and move the bad path test to
a new test file, marking it unsupported on Android.
Attempts to fix a bot failure from
634da7a1c6 on an Android bot:
https://lab.llvm.org/buildbot#builders/77/builds/14339
It appears that the chmod is not making the directory unwritable as
expected on this system for some reason. Adopt an approach used in
compiler-rt/test/fuzzer/fuzzer-dirs.test for systems with
non-functioning chmod by including illegal characters in directory.
Add a DirExists mechanism, modeled after FileExists. Use it to guard
creation of the report path directory.
This should avoid failures running the sanitizer in a sandbox where the
file creation attempt causes hard failures, even for an existing
directory. Problem reported on D109794 for ChromeOS in sandbox
(https://issuetracker.google.com/209296420).
Differential Revision: https://reviews.llvm.org/D119495
We run bots on a shared machine and under high load
this test sometimes segfaults.
https://lab.llvm.org/buildbot/#/builders/185/builds/1368
==1952234==XRay FDR init successful.
==1952234==XRay FDR: Not flushing to file, 'no_file_flush=true'.
<...>fdr-reinit.cpp.script: line 4: 1952234 Segmentation fault
XRAY_OPTIONS="verbosity=1" <...>/fdr-reinit.cpp.tmp
Looking at the printed output I think it's happening at:
// Finally, we should signal the sibling thread to stop.
keep_going.clear(std::memory_order_release);
Disabling the test while I try to reproduce.
Fix passing the port and IP address with the wrong endianness
in get_sock_peer_name() that causes the connect() to fail inside
without an outgoing network interface (it's trying to connect
to 1.0.0.127 instead of 127.0.0.1).
Differential Revision: https://reviews.llvm.org/D119461
We don't need precise control over the low-level behavior of these testcases so
C should be preferred for readability.
The new testcases test (1) the base dlopen case (running initializers and
deinitializers), and (2) the serial case of dlopen; dlclose; dlopen; dlclose,
where we expect the initializers and deinitializers to be run twice.
As reported in Issue #41838, `clang` doesn't correctly implement `long
double` on 32-bit Solaris/SPARC: the psABI requires this to be an 128-bit
type. Four sanitizer tests currently `FAIL` for this reason.
While there is a WIP patch to fix `clang` (D89130
<https://reviews.llvm.org/D89130>), it isn't complete yet and I've hit so
many brick walls while trying to finish it that I'm unsure if I ever will.
This patch therefore `XFAIL`s those tests in the meantime.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D119016
This patch updates the MachO platform (both the ORC MachOPlatform class and the
ORC-Runtime macho_platform.* files) to use allocation actions, rather than EPC
calls, to transfer the initializer information scraped from each linked object.
Interactions between the ORC and ORC-Runtime sides of the platform are
substantially redesigned to accomodate the change.
The high-level changes in this patch are:
1. The MachOPlatform::setupJITDylib method now calls into the runtime to set up
a dylib name <-> header mapping, and a dylib state object (JITDylibState).
2. The MachOPlatformPlugin builds an allocation action that calls the
__orc_rt_macho_register_object_platform_sections and
__orc_rt_macho_deregister_object_platform_sections functions in the runtime
to register the address ranges for all "interesting" sections in the object
being allocated (TLS data sections, initializers, language runtime metadata
sections, etc.).
3. The MachOPlatform::rt_getInitializers method (the entry point in the
controller for requests from the runtime for initializer information) is
replaced by MachOPlatform::rt_pushInitializers. The former returned a data
structure containing the "interesting" section address ranges, but these are
now handled by __orc_rt_macho_register_object_platform_sections. The new
rt_pushInitializers method first issues a lookup to trigger materialization
of the "interesting" sections, then returns the dylib dependence tree rooted
at the requested dylib for dlopen to consume. (The dylib dependence tree is
returned by rt_pushInitializers, rather than being handled by some dedicated
call, because rt_pushInitializers can alter the dependence tree).
The advantage of these changes (beyond the performance advantages of using
allocation actions) is that it moves more information about the materialized
portions of the JITDylib into the executor. This tends to make the runtime
easier to reason about, e.g. the implementation of dlopen in the runtime is now
recursive, rather than relying on recursive calls in the controller to build a
linear data structure for consumption by the runtime. This change can also make
some operations more efficient, e.g. JITDylibs can be dlclosed and then
re-dlopened without having to pull all initializers over from the controller
again.
In addition to the high-level changes, there are some low-level changes to ORC
and the runtime:
* In ORC, at ExecutionSession teardown time JITDylibs are now destroyed in
reverse creation order. This is on the assumption that the ORC runtime will be
loaded into an earlier dylib that will be used by later JITDylibs. This is a
short-term solution to crashes that arose during testing when the runtime was
torn down before its users. Longer term we will likely destroy dylibs in
dependence order.
* toSPSSerializable(Expected<T> E) is updated to explicitly initialize the T
value, allowing it to be used by Ts that have explicit constructors.
* The ORC runtime now (1) attempts to track ref-counts, and (2) distinguishes
not-yet-processed "interesting" sections from previously processed ones. (1)
is necessary for standard dlopen/dlclose emulation. (2) is intended as a step
towards better REPL support -- it should enable future runtime calls that
run only newly registered initializers ("dlopen_more", "dlopen_additions",
...?).
Aligned new does not require size to be a multiple of alignment, so
memalign is the correct choice instead of aligned_alloc.
Fixes false reports for unaligned sizes.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D119161
Fixes segfaults on x86_64 caused by instrumented code running before
shadow is set up.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D118171
We (Linaro) still have the occasional failure here due
to high load on a shared buildbot machine.
We are looking into general soloutions but perhaps this
will help in the meantime.
Unfortunately, the `sanitizer_common` tests are disabled on many targets
that are supported by `sanitizer_common`, making it easy to miss issues
with that support. This patch enables SPARC testing.
Beside the enabling proper, the patch fixes (together with D91607
<https://reviews.llvm.org/D91607>) the failures of the `symbolize_pc.cpp`,
`symbolize_pc_demangle.cpp`, and `symbolize_pc_inline.cpp` tests. They
lack calls to `__builtin_extract_return_addr`. When those are added, they
`PASS` when compiled with `gcc`. `clang` incorrectly doesn't implement a
non-default `__builtin_extract_return_addr` on several targets, SPARC
included.
Because `__builtin_extract_return_addr(__builtin_return_addr(0))` is quite
a mouthful and I'm uncertain if the code needs to compile with msvc which
appparently has it's own `_ReturnAddress`, I've introduced
`__sanitizer_return_addr` to hide the difference and complexity. Because
on 32-bit SPARC `__builtin_extract_return_addr` differs when the calling
function returns a struct, I've added a testcase for that.
There are a couple more tests failing on SPARC that I will deal with
separately.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D91608
setjmp can return twice, but PostDominatorTree is unaware of this. as
such, it overestimates postdominance, leaving some cases (see attached
compiler-rt) where memory does not get untagged on return. this causes
false positives later in the program execution.
this is a crude workaround to unblock use-after-scope for now, in the
longer term PostDominatorTree should bemade aware of returns_twice
function, as this may cause problems elsewhere.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D118647
These tests appear to be causing timeouts on our silent
Thumbv7 bot: https://lab.llvm.org/staging/#/builders/162/builds/260
It is possible they would complete given enough time. value-profile-switch
seems to take a long time even on a powerful Armv8 machine.
Use s[iu]_int instead of `(unsigned) int` and d[ui]_int instead of
`(unsigned) long long` for LibCall arguments.
Note: the `*vfp` LibCall versions were NOT touched.
Reviewed By: aykevl
Differential Revision: https://reviews.llvm.org/D86546
Fixes a false positive that occurs when a user-implemented memmove is
instrumented by HWASan.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D118180
Use the llvm flag `-pgo-function-entry-coverage` to create single byte "counters" to track functions coverage. This mode has significantly less size overhead in both code and data because
* We mark a function as "covered" with a store instead of an increment which generally requires fewer assembly instructions
* We use a single byte per function rather than 8 bytes per block
The trade off of course is that this mode only tells you if a function has been covered. This is useful, for example, to detect dead code.
When combined with debug info correlation [0] we are able to create an instrumented Clang binary that is only 150M (the vanilla Clang binary is 143M). That is an overhead of 7M (4.9%) compared to the default instrumentation (without value profiling) which has an overhead of 31M (21.7%).
[0] https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4
Reviewed By: kyulee
Differential Revision: https://reviews.llvm.org/D116180
This is a follow up to D118101, that added bexpfull to the test on instrprof-get-filename-merge-mode.c AIX, in order to get the
necessary symbols exported. But unfortunately the extra dependent symbols this exports actually cause segfaults, which is why
this isn't really recommended in the first place, so just use an actual export list.
Differential Revision: https://reviews.llvm.org/D118310
Use the `llvm-profdata show` command to verify debug info for profile correlation using the `--debug-info` option.
Reviewed By: kyulee
Differential Revision: https://reviews.llvm.org/D118181
There is no need to compress the names string when correlating with
debug info since InstrProfReader will immediately uncompress it anyway.
This also removes the dependency on zlib in this case.
Reviewed By: kyulee
Differential Revision: https://reviews.llvm.org/D118176
The AIX linker doesn't export any symbols by default, so an export list is usually used. Since clang doesn't have the tools to auto-generate an export list yet, just pass the linker an extra opt to tell it to export everything. This is generally not recommended for real shared libs, but is fine for the purpose of this test.
Differential Revision: https://reviews.llvm.org/D118101
1b1c8d changed `enable-noundef-analysis` flag to
`disable-noundef-analysis`. noundef_analysis.cpp was using old
`enable-noundef-analysis` flag and this patch fixes it.
Existing code tended to assume that counters had type `uint64_t` and
computed size from the number of counters. Fix this code to directly
compute the counters size in number of bytes where possible. When the
number of counters is needed, use `__llvm_profile_counter_entry_size()`
or `getCounterTypeSize()`. In a later diff these functions will depend
on the profile mode.
Change the meaning of `DataSize` and `CountersSize` to make them more clear.
* `DataSize` (`CountersSize`) - the size of the data (counter) section in bytes.
* `NumData` (`NumCounters`) - the number of data (counter) entries.
Reviewed By: kyulee
Differential Revision: https://reviews.llvm.org/D116179
The test checks that an array of Obj-C literal integers (e.g. `@1`) gets a UBSan
warning when cast to an NSString, however the actual concrete Obj-C class of
literal integers doesn't always need to be __NSCFNumber. Let's relax the test
expectations to allow NSConstantIntegerNumber. Which exact subclass of NSNumber
is used is not actually important for the test (the test is just checking that
the invalid cast warning is thrown).
Julian Lettner