https://github.com/llvm/llvm-project/pull/78285 added a test which calls
`__llvm_orderfile_dump()`, a functionality that is not supported on many
platforms. This PR removes the call to `__llvm_orderfile_dump()` to
avoid it failing on unsupported platforms, and turn on the test for
Windows, so we test the rest of the API that are supported.
In the test from https://reviews.llvm.org/D7098, `char array[len];` is
32-byte aligned on most targets whether it is instrumented or not
(optimized by StackSafetyAnalysis), due to the the used `*FrameLowering`
being `StackRealignable`.
However, when using `SystemZELFFrameLowering`, an un-instrumented
`char array[len];` is only 8-byte aligned.
Ensure `char array[len];` gets instrumented like what we did to
`alloca_vla_interact.cpp`, to make the test pass on s390x.
The test fails on Darwin, see comment on the PR.
> std:: usually is not a cause of the bug.
>
> We now display
> ```
> SUMMARY: AddressSanitizer: allocation-size-too-big path/to/allocator_returns_null.cpp:92:7 in main
> ```
> instead of
>
> ```
> SUMMARY: AddressSanitizer: allocation-size-too-big /usr/lib/../include/c++/13/bits/new_allocator.h:147:27 in std::__new_allocator<char>::allocate(unsigned long, void const*)
> ```
>
> `/include/c++/` matches both libc++ and libstdc++ include paths.
This reverts commit ecd47811b755d13357085bcd7519a66d6c4d8e5c.
The test (from https://reviews.llvm.org/D7098) is about the interaction
of VLA and alloca where the VLA causes alloca to have the same address.
This is mostly about behavior checking and less about instrumentation
correctness, so I think it is fair to disable it for a platform that
does not work after StackSafetyAnalysis is enabled by default (#77210).
This ports msan https://reviews.llvm.org/D14795 to dfsan.
dfsan, like msan, clears shadow for globals in a newly opened DSO in
case the DSO occupies the address of a previously labeled/poisoned area.
The operation should not happen on the main executable.
In addition, for a DT_EXEC executable, l_addr is zero and will lead to a
null pointer dereference in ForEachMappedRegion.
std:: usually is not a cause of the bug.
We now display
```
SUMMARY: AddressSanitizer: allocation-size-too-big path/to/allocator_returns_null.cpp:92:7 in main
```
instead of
```
SUMMARY: AddressSanitizer: allocation-size-too-big /usr/lib/../include/c++/13/bits/new_allocator.h:147:27 in std::__new_allocator<char>::allocate(unsigned long, void const*)
```
`/include/c++/` matches both libc++ and libstdc++ include paths.
explicitly pass libLTO path. This fixes a failure in swift-ci where
libLTO was being picked from the system instead which was an older
version and caused issues.
rdar://117474861
snprintf interceptors call `format_buffer` with `size==~0ul`, which
may eventually lead to `snprintf(s, n, "Hello world!")` where `s+n`
wraps around. Since glibc 2.37 (https://sourceware.org/PR30441), the
snprintf call does not write the last char. musl snprintf returns -1
with EOVERFLOW when `n > INT_MAX`.
Change `size` to INT_MAX to work with glibc 2.37+ and musl.
snprintf interceptors are not changed. It's user responsibility to not
cause a compatibility issue with libc implementations.
Fix#60678
StackSafetyAnalysis determines whether stack-allocated variables are
guaranteed to be safe from memory access bugs and enables the removal of
certain unneeded instrumentations.
(hwasan enables StackSafetyAnalysis in https://reviews.llvm.org/D108381)
In a release build of clang, text sections are 9% smaller.
Test updates:
* asan-stack-safety.ll: test the -asan-use-stack-safety=1 default
* lifetime-uar-uas.ll: switch to an indexed store to prevent
StackSafetyAnalysis from optimizing out instrumentation for %c
* alloca_vla_interact.cpp: add a load to prevent StackSafetyAnalysis
from optimizing out `__asan_alloca_poison` for the VLA `array`
* scariness_score_test.cpp: add -asan-use-stack-safety=0 to make a load
of a `__asan_poison_memory_region`-poisoned local variable fail as
intended.
* other .ll tests: add -asan-use-stack-safety=0
Reviewed By: kstoimenov
Pull Request: https://github.com/llvm/llvm-project/pull/77210
Calling one of pthread join/detach interceptor on an already
joined/detached thread causes asserts such as:
AddressSanitizer: CHECK failed: sanitizer_thread_arg_retval.cpp:56
"((t)) != (0)" (0x0, 0x0) (tid=1236094)
#0 0x555555634f8b in __asan::CheckUnwind()
compiler-rt/lib/asan/asan_rtl.cpp:69:3
#1 0x55555564e06e in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:86:24
#2 0x5555556491df in __sanitizer::ThreadArgRetval::BeforeJoin(unsigned
long) const
compiler-rt/lib/sanitizer_common/sanitizer_thread_arg_retval.cpp:56:3
#3 0x5555556198ed in Join<___interceptor_pthread_tryjoin_np(void*,
void**)::<lambda()> >
compiler-rt/lib/asan/../sanitizer_common/sanitizer_thread_arg_retval.h:74:26
#4 0x5555556198ed in pthread_tryjoin_np
compiler-rt/lib/asan/asan_interceptors.cpp:311:29
The assert are replaced by error codes.
StackSafetyAnalysis determines whether stack-allocated variables are
guaranteed to be safe from memory access bugs and enables the removal of
certain unneeded instrumentations.
(hwasan enables StackSafetyAnalysis in https://reviews.llvm.org/D108381)
Test updates:
* asan-stack-safety.ll: test the -asan-use-stack-safety=1 default
* lifetime-uar-uas.ll: switch to an indexed store to prevent
StackSafetyAnalysis from optimizing out instrumentation for %c
* alloca_vla_interact.cpp: add a load to prevent StackSafetyAnalysis
from optimizing out `__asan_alloca_poison` for the VLA `array`
* scariness_score_test.cpp: add -asan-use-stack-safety=0 to make a load
of a `__asan_poison_memory_region`-poisoned local variable fail as
intended.
* other .ll tests: add -asan-use-stack-safety=0
Reviewers: kstoimenov, eugenis, vitalybuka
Reviewed By: kstoimenov
Pull Request: https://github.com/llvm/llvm-project/pull/77210
This PR exposes four PGO functions
- `__llvm_profile_set_filename`
- `__llvm_profile_reset_counters`,
- `__llvm_profile_dump`
- `__llvm_orderfile_dump`
to user programs through the new header `instr_prof_interface.h` under
`compiler-rt/include/profile`. This way, the user can include the header
`profile/instr_prof_interface.h` to introduce these four names to their
programs.
Additionally, this PR defines macro `__LLVM_INSTR_PROFILE_GENERATE` when
the program is compiled with profile generation, and defines macro
`__LLVM_INSTR_PROFILE_USE` when the program is compiled with profile
use. `__LLVM_INSTR_PROFILE_GENERATE` together with
`instr_prof_interface.h` define the PGO functions only when the program
is compiled with profile generation. When profile generation is off,
these PGO functions are defined away and leave no trace in the user's
program.
Background:
https://discourse.llvm.org/t/pgo-are-the-llvm-profile-functions-stable-c-apis-across-llvm-releases/75832
Change the format of IRPGO counter names to
`[<filepath>;]<mangled-name>` which is computed by
`GlobalValue::getGlobalIdentifier()` to fix#74565.
In fe051934cbb0aaf25d960d7d45305135635d650b
(https://reviews.llvm.org/D156569) the format of IRPGO counter names was
changed to be `[<filepath>;]<linkage-name>` where `<linkage-name>` is
basically `F.getName()` with some prefix, e.g., `_` or `l_` on Mach-O
(yes, it is confusing that `<linkage-name>` is computed with
`Mangler().getNameWithPrefix()` while `<mangled-name>` is just
`F.getName()`). We discovered in #74565 that this causes some missed
import issues on some targets and #74008 is a partial fix.
Since `<mangled-name>` may not match the `<linkage-name>` on some
targets like Mach-O, we will need to post-process the output of
`llvm-profdata order` before passing to the linker via `-order_file`.
Profiles generated after fe051934cbb0aaf25d960d7d45305135635d650b will
become stale after this diff, but I think this is acceptable since that
patch landed after the LLVM 18 cut which hasn't been released yet.
When merging instrFDO profiles with afdo profile as supplementary, instrFDO counters for static functions are stored with function's PGO name (with filename.cpp; prefix).
- This pull request fixes the delimiter used when a PGO function name is 'normalized' for AFDO look-up.
Temporarily fix for issue #76545
Hwasan does not attach tags to @llvm.dbg.assign. It's not clear if we
can attach tags to @llvm.dbg.assign.
For now we just disable the path replacing llvm.dbg.declare with
llvm.dbg.assign.
It may reduce the quality of interactive debugging with HWASAN, but
usually it's
a smaller priority for sanitizers than the quality if reports.
The test failure is about failed to build instrumented binary on ppc
(https://lab.llvm.org/buildbot/#/builders/18/builds/13228). Not sure how
to fix this for now. Mark the test unsupported on ppc.
```
RUN: at line 46: /home/buildbots/ppc64be-sanitizer/sanitizer-ppc64be/build/build_gcc/./bin/clang --driver-mode=g++ -m64 -ldl -fprofile-generate -fuse-ld=lld -O2 lib.cpp main.cpp -o main
+ /home/buildbots/ppc64be-sanitizer/sanitizer-ppc64be/build/build_gcc/./bin/clang --driver-mode=g++ -m64 -ldl -fprofile-generate -fuse-ld=lld -O2 lib.cpp main.cpp -o main
ld.lld: error: /lib/../lib64/Scrt1.o: ABI version 1 is not supported
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
- The IR test failed to import indirect callees on big-endian systems.
The raw profiles are generated on little-endian systems. Going to
require little-endian.
- Limit the compiler-rt test to three tested platforms.
Simplify the compiler-rt test to make it more general for different
platforms, and use `*DAG` matchers for lines that may be emitted
out-of-order.
- The compiler-rt test passed on a Windows machine. Previously name
matchers don't work for MSVC mangling
(https://lab.llvm.org/buildbot/#/builders/127/builds/59907)
- `*DAG` matchers fixed the error in
https://lab.llvm.org/buildbot/#/builders/94/builds/17924
This is the second reland and fixed errors caught in first reland
(https://github.com/llvm/llvm-project/pull/75860)
**Original commit message**
Commit fe05193 (phab D156569), IRPGO names uses format
`[<filepath>;]<linkage-name>` while prior format is
`[<filepath>:<mangled-name>`. The format change would break the use case
demonstrated in (updated)
`llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll` and
`compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp`
This patch changes `GlobalValues::getGlobalIdentifer` to use the
semicolon.
To elaborate on the scenario how things break without this PR
1. IRPGO raw profiles stores (compressed) IRPGO names of functions in
one section, and per-function profile data in another section. The
[NameRef](fc715e4cd9/compiler-rt/include/profile/InstrProfData.inc (L72))
field in per-function profile data is the MD5 hash of IRPGO names.
2. When raw profiles are converted to indexed format profiles, the
profiled address is
[mapped](fc715e4cd9/llvm/lib/ProfileData/InstrProf.cpp (L876-L885))
to the MD5 hash of the callee.
3. In `pgo-instr-use` thin-lto prelink pipeline, MD5 hash of IRPGO names
will be
[annotated](fc715e4cd9/llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp (L1707))
as value profiles, and used to import indirect-call-prom candidates. If
the annotated MD5 hash is computed from the new format while import uses
the prior format, the callee cannot be imported.
*
`compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp`
is added to have an end-to-end test.
* `llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll`
is updated to have better test coverage from another aspect (as runtime
tests are more sensitive to the environment and may be skipped by some
contributors)
