The marked library(ies) were available to the APEXes via the
hand-written whitelist in build/soong/apex/apex.go. Trying to remove the
whitelist by adding apex_available property to the Android.bp of the
libraries.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 150999716
Test: m
Merged-In: I54db09314c7236a227f04281a439c1d5dc56ef2c
Change-Id: I54db09314c7236a227f04281a439c1d5dc56ef2c
(cherry picked from commit a2606921b2)
In addition, move a couple of elf benchmarks out of unwind_benchmarks.cpp
to the ElfBenchmarks.cpp file.
Test: Ran benchmarks.
Change-Id: I169f89f7b2dd6735568143f2176301e181fb8262
Libunwindstack would remove duplicated items and update the `prev_map`
during reparsing `/proc/self/maps`. But we leave `prev_real_map`
pointing toward a MapInfo that will be deleted soon. It will cause a
dangling pointer issue.
Add new tests to cover this dangling pointer issue.
Bug: 155511785
Test: libunwindstack_test
Change-Id: I62e1b97bcb73f07e9349671f0b758f5ec9de16c0
Relanding unchanged - the build problem was due to a split topic.
Test: m checkbuild
Test: atest libunwindstack_unit_test
Test: lunch fvp-userdebug && mmm system/core/libunwindstack
Bug: 152255951
Change-Id: Ifd1ced65b840ef216630906eec1ec31233e0c5f1
Reason for revert: Breaks rvc-d1-dev-plus-aosp: http://ab/6443190
Reverted Changes:
Ide447b89a:bionic_libc_platform_headers is only available whe...
Ia93cd3ec8:bionic_libc_platform_headers is only available whe...
Icdc495588:Make bionic_platform_headers available only for Bi...
Idfd7c87dc:bionic_libc_platform_headers is only available whe...
Bug: 152255951
Bug: 155269399
Change-Id: I4e6beba5565e604fde3a51cdce5cc4041caffa4e
Tagged pointer for aarch64 since Android R would lead top byte to have
random values. For example of a symbol from libart.so in a hwasan
enabled device in Android R:
1490: 8800000000b094a0 144 OBJECT GLOBAL 24 __dex_debug_descriptor
We need to mask off the top byte so that the address range comparison
would work as intended.
Test: Ran new unit test
Signed-off-by: Yong Li <yongl0722@gmail.com>
Change-Id: Ia8c638e16baff57740c569e9eaf9cfd1f5bd3fad
This function is responsible for majority of CPU time in prefetto.
Reduce the number of memory reads (don't read strings byte-by-byte).
Update all calls of ReadString to include the third parameter to have
a max read.
Add an Elf creation benchmark since this function is on the elf
creation path.
Test: libunwindstack_unit_test
Change-Id: Ia36e1f1a5ba76c9e9f13c43fb9e3691dde7897f2
ELF symbols are not sorted by address. Create remap table
which reshuffles the indices into sorted-by-address order.
This saves over 6x of memory (the remap table needs just
uint32_t per entry, as opposed the FuncInfo cache entry).
ART symbols are sorted. Make use of that fact.
Bug: 110133331
Test: libunwindstack_test
Test: art/test.py -b --host -r -t 137-cfi
Change-Id: I1812d2dd3ad6a69ae93ed50ca387749c649289b9
This uses an experimental Linux kernel API for reading the tags across
processes using ptrace.
Bug: 135772972
Test: Unit tests pass.
Change-Id: Ib1a09d9219166011de80cf250b756bb8a4bcdb0a
Add a number of benchmarks to time how long it takes to look
up symbols.
Test: Ran benchmarks on device.
Change-Id: Iab7aab3f60c2c7056395beca3d36263420bcb5dc
If the Dex file we're trying to examine is already within the unwinder's
address space, we don't need to load it from disk or copy it across
processes.
This avoids using up virtual address space to map in dex files, and
also should be a bit faster to read since it won't go out to the file.
Patch by Chris Sarbora
Test: Ran new unit tests.
Test: Ran 137-cfi art test.
Change-Id: I949457856f051cca11b9020e9da3a41bbf6e5c8e
This was sometimes causing build ids to be truncated, probably because
of memory corruption in std::string. A similar off-by-one was fixed in
ReadBuildID in aosp/939619.
Bug: 129873279
Change-Id: I401fe7f991dbd135f5b4836381b48ea3c6a2243f
GWP-ASan uses frame-pointer based unwinding internally on
allocation/deallocation to collect stack traces that are used when
crashes are reported.
This should be generic, so pull it out into libunwindstack so it can be
used by MTE as well.
Bug: 152412331
Test: atest debuggerd_test
Change-Id: I27b32263aac63446f5fe398af108676b70cd3971
The DexFile handle is allocated from heap in OpenFromFd/OpenFromMemory.
After releasing the unique_ptr, the DexFile handle itself is no longer
managed by the smart pointer. However, the DexFile handle is not freed
in the constructor of DexFileFromFile/DexFileFromMemory.
This change uses get() method to get the DexFile pointer while allowing
it to be managed by smart pointer so that it can be freed after method
end.
Added new unit tests to detect leaks.
Bug: 151966190
Test: Unwinding can still retrieve dex frame information during crash.
Test: Ran new unit tests before change and verified they fail, ran them
Test: after the change and verified they don't fail.
Signed-off-by: Yong Li <yongl0722@gmail.com>
Change-Id: I0627e1e255eb6644aba51e940c1a79ff78d568d7
We're now using it in contexts that don't have all of the registers available,
such as GWP-ASan and soon MTE, so it doesn't make sense to have it be a
member function of Regs.
Bug: 135772972
Change-Id: I18b104ea0adb78588d7e475d0624cefc701ba52c
- Create a static library libunwindstack_no_dex without DEX support.
- Use it in libdebuggerd_handler_fallback, whose only use is in the
linker, which shouldn't need that support.
- Use it in init_first_stage, which doesn't need DEX support either.
- Also need a libbacktrace_no_dex since it's in the dependency chain
from init_first_stage to libunwindstack_no_dex.
Also restrict the *_no_dex libs and libdebuggerd_handler_fallback as
much as possible to avoid inadvertent use of these reduced
functionality libs.
Test: m init_first_stage on Cuttlefish
where BOARD_BUILD_SYSTEM_ROOT_IMAGE=false
Test: m system_image com.android.runtime
Test: Build & boot
Test: atest linker-unit-tests libunwindstack_unit_test debuggerd_test
Bug: 142944931
Bug: 151466650
Change-Id: Iaacb29bfe602f3ca12a00a712e2a64c45ff0118b
For now this leaves the ability to cross-unwind a mips process, but we
should probably clean that up too. We need to remove the build remnants so
that we can clean up the build system itself (otherwise it sees us talking
about an architecture it doesn't know about, and assumes that something's
wrong).
Test: treehugger
Change-Id: I2862c630cec95dbdd474e34c3568d0e1a6d44b16
Simplify and fix the algorithm.
For consecutive functions (eg [10,20] [20,30]) without
padding in between, the old algorithm would drop FDEs.
Test: libunwindstack_test
Change-Id: Ie886922bec262fb64d4b2ecf01c2961d0652dcdb
The memcpy should be for 31 GPRs, [x0, x30]. Currently it (accidentally)
also copies over the SP register (which ends up being harmless, as the
layouts match, and the value is reassigned again anyway).
Separately, I'm including an optional change for the iteration order,
since LR is the x30 GPR, it makes slightly more sense to print it
immediately after x29. However, this is a change in behaviour, so I can
undo the change if you think it's not worth it.
Tested: atest libunwindstack_unit_test
Change-Id: Ib6b81f8ee3a9a526bfabe4b09b327f083c855fb8
Recently, the maps for an elf in memory might show up looking like:
f0000-f1000 0 r-- /system/lib/libc.so
f1000-f2000 0 ---
f2000-f3000 1000 r-x /system/lib/libc.so
f3000-f4000 2000 rw- /system/lib/libc.so
The problem is that there is logic in the code that assumed that the
map before the execute map must be the read-only map. In the case
above, this is not true. Add a new prev_real_map that will point
to the previous map that is not one of these empty maps.
This will fix the backtraces that look like this:
#00 pc 0000000000050d58 /apex/com.android.runtime/lib64/bionic/libc.so!libc.so (offset 0x50000) (syscall+24) (BuildId: 5252408bf30e395d49ee270b54c77ca4)
To get rid of the !libc.so and the offset value, which is not correct.
Added new unit tests to verify this.
Added new offline test which an empty map between read-only and execute
map. Before this change, the backtraces had lines like
libc.so!libc.so (offset XXX) would be present.
Bug: 148075852
Test: Ran unit tests.
Change-Id: Ie04bfc96b8f91ed885cb1e655cf1e346efe48a45
Recently, the maps for an elf in memory might show up looking like:
f0000-f1000 0 r-- /system/lib/libc.so
f1000-f2000 0 ---
f2000-f3000 1000 r-x /system/lib/libc.so
f3000-f4000 2000 rw- /system/lib/libc.so
That empty map was confusing the logic when looking for a global
variable. Now this case is handled properly.
New unit test added for this case.
Bug: 147910661
Test: Ran unit tests.
Test: Ran original failing test 137-cfi.
Change-Id: Ida2e96d1da5e1bf61f41646949fe5a2d405c0d61
Rather than use a std::vector for backing memory, allocate the memory
using a new with nothrow, and in MemoryBuffer use realloc. Since
the size field is coming from the elf, it could be corrupted or
intentionally crafted to cause problems.
In addition, add some other protections to make sure that overflows
don't occur.
Bug: 146215949
Test: Ran unit tests with jemalloc and scudo to verify that they
Test: both behave the same way.
Change-Id: If14243ce382ba5403a6bacd0ec673452c6b7c3be
The function StepIfSignalHandler assumed that the rel_pc passed
to it was actually an elf offset. A new version of clang created a libc.so
that has a load bias, so tests unwinding through a signal handler
would fail on arm. On other ABIs, there is unwind information that could
be used instead, so the unwind still worked.
The fix is to subtract the load bias from the rel_pc to get an elf
offset to pass to the Register StepIfSignalHandler functions. Change all
of the Register funtions to make it clear what the first parameter means.
Add a unit test for this new code. Also, add an offline test for
this case.
Bug: 145683525
Test: Ran unit tests using the new clang and the old clang.
Change-Id: I3e249653b79bcad6d3a56411a7911fde4888e9d6
The code was not properly getting the variable addresses and using
the offset and address fields of the .data section.
Fix all of that, and update the tests.
Bug: 145162678
Test: Unit tests pass.
Test: ./art/test/run-test --dex2oat-jobs 4 --host --prebuild --compact-dex-level fast --jit --no-relocate --runtime-option -Xcheck:jni 137-cfi
Test: ./art/test/testrunner/testrunner.py -t 137 --host
Change-Id: Ic61c4487334fd2273cda9c56eb1a3b525a03edb7
No longer require that NO_LIBDEXFILE_SUPPORT be defined or not
defined when including the header files. Move all of the different
behavior to the implementation, and keep all of the classes the
exact same whether dexfiles are supported or not.
Bug: 144470551
Test: Ran libunwindstack unit tests, libbacktrace unit tests, and
Test: debuggerd unit tests.
Test: Ran host art 137-cfi tests.
Change-Id: I4a04cfbc5d4f1bf765ef154881046c85057006c8
A thread's PSTATE can sometimes be critical for understanding a crash,
especially with MTE and other new features that store per-thread state
in PSTATE.
Bug: 135772972
Change-Id: I1bee25bffe7eea395f04b6449dc9227298cf866e
Previously, when reparsing /proc/self/maps, we would remove duplicate
MapInfo entries, but leave the following entry's prev_map pointing
toward the soon-to-be-deleted MapInfo, leading to explosions.
Test: libunwindstack_test
Test: booted with libfdtrack.so preloaded
Change-Id: Ibfb7a8712540fe3aaadc10e9c31938f6ecddf17b
Due to a bug, an elf can have FDEs with a length of zero, while still
having another FDE for the same pc with a non-zero length. The
eh_frame_hdr can sometimes point to the zero length FDE, but it should
have pointed to the non-zero length FDE. In order to fix this, if the
eh_frame_hdr points at the zero length FDE then try and find the real FDE
directly from eh_frame.
The change cleans up and removes unused variables from DwarfEhFrameWithHdr
and changes the objects so that all of the DwarfSection objects and
DwarfEhFrameWithHdr object inherit from the same class.
Add new unit tests to verify this functionality.
Bug: 142483624
Test: Unit tests all pass.
Change-Id: I128a916e3ba378931de7d44ee15e57e24d4073df
The bias for the PT_GNU_EH_FRAME was using the paddr instead of vaddr.
This doesn't match the way the load bias is calculated, which always
use vaddr - offset, so change to use vaddr.
Found on an old x86 device that has a vdso that sets vaddr differently
from paddr.
Add a new offline test to catch this case and update the elf interface
unit tests.
Also, fix a small bug in the unwind_for_offline tool.
Bug: 142365899
Test: Unit tests pass.
Change-Id: I5f0bf062dd8ee45aa8553189ba493ec962e0b059
This document does not list every change in the unwinder between
Android versions. Instead it attempts to only include information
that someone building an app targeting a specific version of Android
might need to know to make sure their app can unwind properly.
It also tries to describe the way that stacktraces might be displayed
differently between Android versions.
Test: NA
Change-Id: I4029053f763f3471f7ddb5da9b1de2d325ead455
