SetThreadDescription symbol needs to be dynamically loaded before usage.
Then using a wide string buffer, since we re using a null terminated
string, we can use MultiByteToWideChar -1 as 4th argument to finally set
the thread name.
Previously `SetThreadDescription` was called directly causing crash.
It was reverted in dd3aa26fc8e9de37a39611f7a6a602bcb4153784
Don't use multiple tagged pages at the beginning of an allocation, since
it prevents using such allocations for memrefs, and mappings aren't
reused anyway since Trusty uses MapAllocatorNoCache.
Upstreamed from https://r.android.com/2537251.
Co-authored-by: Marco Nelissen <marcone@google.com>
Most of GCC's Linux targets have a link spec
`%{!static|static-pie:--eh-frame-hdr}` that doesn't pass --eh-frame-hdr
for `-static` links. `-static` links are supposed to utilize
`__register_frame_info` (called by `crtbeginT.o`, not by crtbegin.o or
crtbeginS.o) as a replacement.
compiler-rt crtbegin (not used with GCC) has some ehframe code, which is
not utilized because Clang driver unconditionally passes --eh-frame-hdr
for Linux targets, even for -static. In addition, LLVM libunwind
implements `__register_frame_info` as an empty stub.
Furthermore, in a non-static link, the `__register_frame_info`
references can cause an undesired weak dynamic symbol.
For now, just disable the config by default.
When building a standalone build with
`-DLLVM_CMAKE_DIR=$HOME/output/llvm-install
-DCOMPILER_RT_INCLUDE_TESTS=ON`, the current code will attempt to use
`LLVM_DEFAULT_EXTERNAL_LIT` which is set to
`$HOME/output/llvm-install/bin/llvm-lit` inside `LLVMConfig.cmake` even
though it is not actually installed. If we are adding the llvm-lit
subdirectory, we can use `get_llvm_lit_path()` immediately afterwards to
set LLVM_EXTERNAL_LIT so that subsequent calls within
`add_lit_testsuite()` use llvm-lit from the current build directory
instead of the nonexistant one.
Without this change I am seeing build failures due to missing
std::next_permutation since my standard library does implicitly pull
in <algorithm> anymore.
New change on top of [reviewed
patch](https://github.com/llvm/llvm-project/pull/81691) are [in commits
after this
one](d0757f46b3).
Previous commits are restored from the remote branch with timestamps.
1. Fix build breakage for non-ELF platforms, by defining the missing
functions {`__llvm_profile_begin_vtables`, `__llvm_profile_end_vtables`,
`__llvm_profile_begin_vtabnames `, `__llvm_profile_end_vtabnames`}
everywhere.
* Tested on mac laptop (for darwins) and Windows. Specifically,
functions in `InstrProfilingPlatformWindows.c` returns `NULL` to make it
more explicit that type prof isn't supported; see comments for the
reason.
* For the rest (AIX, other), mostly follow existing examples (like this
[one](f95b2f1acf))
2. Rename `__llvm_prf_vtabnames` -> `__llvm_prf_vns` for shorter section
name, and make returned pointers
[const](a825d2a4ec (diff-4de780ce726d76b7abc9d3353aef95013e7b21e7bda01be8940cc6574fb0b5ffR120-R121))
**Original Description**
* Raw profile format
- Header: records the byte size of compressed vtable names, and the
number of profiled vtable entries (call it `VTableProfData`). Header
also records padded bytes of each section.
- Payload: adds a section for compressed vtable names, and a section to
store `VTableProfData`. Both sections are padded so the size is a
multiple of 8.
* Indexed profile format
- Header: records the byte offset of compressed vtable names.
- Payload: adds a section to store compressed vtable names. This section
is used by `llvm-profdata` to show the list of vtables profiled for an
instrumented site.
[The originally reviewed
patch](https://github.com/llvm/llvm-project/pull/66825) will have
profile reader/write change and llvm-profdata change.
- To ensure this PR has all the necessary profile format change along
with profile version bump, created a copy of the originally reviewed
patch in https://github.com/llvm/llvm-project/pull/80761. The copy
doesn't have profile format change, but it has the set of tests which
covers type profile generation, profile read and profile merge. Tests
pass there.
rfc in
https://discourse.llvm.org/t/rfc-dynamic-type-profiling-and-optimizations-in-llvm/74600
---------
Co-authored-by: modiking <modiking213@gmail.com>
Reverts llvm/llvm-project#70390
There's a bug caught by
`ScudoCombinedTestReallocateInPlaceStress_DefaultConfig.ReallocateInPlaceStress`
with gwp asan. It's an easy fix but given that this is a major change, I
would like to revert it first
This patch inserts 1-byte counters instead of an 8-byte counters into
llvm profiles for source-based code coverage. The origial idea was
proposed as block-cov for PGO, and this patch repurposes that idea for
coverage: https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4
The current 8-byte counters mechanism add counters to minimal regions,
and infer the counters in the remaining regions via adding or
subtracting counters. For example, it infers the counter in the if.else
region by subtracting the counters between if.entry and if.then regions
in an if statement. Whenever there is a control-flow merge, it adds the
counters from all the incoming regions. However, we are not going to be
able to infer counters by subtracting two execution counts when using
single-byte counters. Therefore, this patch conservatively inserts
additional counters for the cases where we need to add or subtract
counters.
RFC:
https://discourse.llvm.org/t/rfc-single-byte-counters-for-source-based-code-coverage/75685
Instead of always storing the same number of blocks as cached, we prefer
increasing the utilization by saving more blocks in a single
TransferBatch. This may slightly impact the performance, but it will
save a lot of memory used by BatchClassId (especially for larger
blocks).
This is a follow up of
7b9d73c2f9
and
5ef9ba7412
* The definition of `Type::getInt8PtrTy` is deleted. This doesn't cause
a compile error because the `Initializer` part of the macro doesn't run.
8 was very low and it is likely that in real workloads we have more than
an average of 8 frames per stack given on Android we have 3 at the
bottom: __start_main, __libc_init, main, and three at the top: malloc,
scudo_malloc and Allocator::allocate. That leaves 2 frames for
application code, which is clearly unreasonable.
* Raw profile format
- Header: records the byte size of compressed vtable names, and the
number of profiled vtable entries (call it `VTableProfData`). Header
also records padded bytes of each section.
- Payload: adds a section for compressed vtable names, and a section to
store `VTableProfData`. Both sections are padded so the size is a
multiple of 8.
* Indexed profile format
- Header: records the byte offset of compressed vtable names.
- Payload: adds a section to store compressed vtable names. This section
is used by `llvm-profdata` to show the list of vtables profiled for an
instrumented site.
[The originally reviewed
patch](https://github.com/llvm/llvm-project/pull/66825) will have
profile reader/write change and llvm-profdata change.
- To ensure this PR has all the necessary profile format change along
with profile version bump, created a copy of the originally reviewed
patch in https://github.com/llvm/llvm-project/pull/80761. The copy
doesn't have profile format change, but it has the set of tests which
covers type profile generation, profile read and profile merge. Tests
pass there.
rfc in
https://discourse.llvm.org/t/rfc-dynamic-type-profiling-and-optimizations-in-llvm/74600
---------
Co-authored-by: modiking <modiking213@gmail.com>
As of #77488, UnmapOrDie now accepts raw_report which allows the program
to crash without calling Report(). We should propogate this value
through UnmapOrDieVmar and have that call ReportMunmapFailureAndDie
which uses `raw_report`.
This re-lands cc0065a7d082f0bd322a538cf62cfaef1c8f89f8 in a way that
keeps existing targets working.
---------
Original commit message:
#68132 ended up removing
__multc3 & __divtc3 from compiler-rt library builds that have
QUAD_PRECISION but not TF_MODE due to missing int128 support.
I added support for QUAD_PRECISION to use the native hex float long double representation.
---------
Co-authored-by: Sean Perry <perry@ca.ibm.com>
Allow pre-release APIs on pre-release devices.
The current implementation requires __ANDROID_API_FUTURE__ to use new
APIs on pre-release system. This makes it hard to maintain the codebase
because it should be switched a concrete version (e.g. __ANDROID_API_X__
on release of X).
Instead, we can just allow pre-release APIs on pre-release system
without mandating the major version of __ANDROID_API_FUTURE__.
Note that this doesn't make API guards just no-op in pre-release builds.
We can still rely on its compile-time checks and it still works as
expected with release builds. Even with pre-release builds, it's the
same as before because we would pass __ANDROID_API_FUTURE__ to make the
calls anyway.
This updates the signal handle thread coordinating to use a user signal
bit on the SignalHandlerEvent to coordinate shutdown instead of closing
the event handle. Closing the event handle is racy as the handle may be
closed before the signal handler thread resolves the handle value in
_zx_object_wait_many() and we would like to make this an explicit error.
Using the user signal bit 1 instead and then closing the event object
after the signal handler thread is joined cannot race as the wait will
terminate whether the signal is raised before or after the wait begins.
- Add a param `raw_report` which defaults to false for function
`UnmapOrDie()` like we do for `MmapOrDie()`
- Add a template param `raw_report` which defaults to false for class
`InternalMmapVectorNoCtor`. `raw_report` will be passed to `MmapOrDie()`
and `UnmapOrDie()` when they are called in class
`InternalMmapVectorNoCtor` member functions.
- Use `InternalMmapVectorNoCtor<char, true>` for `error_message_buffer`
and reallocate if needed.
The `_DYNAMIC` reference from `AsanDoesNotSupportStaticLinkage` ensures
that `clang++ -fsanitize=address -static` gets a linker error.
`MemprofDoesNotSupportStaticLinkage` is similar for `-fmemory-profile`.
Move the functions to sanitizer_common.h to be used by more sanitizers
on ELF platforms.
Fuchsia does not use interposition and opts out the check (its
`AsanDoesNotSupportStaticLinkage` is a no-op).
First commit of the stack is a clean reland, second is the fix.
There was a typo in the `static_assert` that meant we were asserting the
size of the pointer, not the struct.
Also changed `alignas` to be more intuitive, but that is NFC.
Ran builds in Android here: https://r.android.com/2954411
As detailed in [GCC PR
sanitizer/113785](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785),
the GCC test `c-c++-common/asan/swapcontext-test-1.c` `FAIL`s on
Solaris/sparc.
This is due to the fact that Solaris 10/SPARC changed the semantics of
`makecontext` so `ucontext_t.uc_stack.ss_sp` refers to the stack base
address. To maintain binary compatiblity, the external name was changed
to `__makecontext_v2`, keeping the old version.
To match this, `__makecontext_v2` needs to be intercepted instead of
`makecontext`.
Tested on GCC trunk on `sparc-sun-solaris2.11`, `i386-pc-solaris2.11`,
and `x86_64-pc-linux-gnu`.
Also tested on the same targets on LLVM `main`. However, this only
proves that Linux/x86_64 isn't broken, since all `makecontext` tests are
Linux-specific.
Existing code worked only for local, recorder FP, and the faulty address
are the same 1 MiB page.
Now, instead of guessing FP, we guess variable address.
We need to try just two cases of addresses around of faulty one.
Fixes https://github.com/google/sanitizers/issues/1723
