With VNDK APEX, the path for VNDK libs has been changed
from /system/lib/vndk-VER to /apex/com.android.vndk.vVER/lib
In most cases, vndk version can be substituted when generating
ld.config.txt by linkerconfig.
But, ld.config.txt files in APEX packages still rely on runtime substitution.
Specifically, com.android.media.swcodec is using VNDK_VER variable.
Moreover, it cannot migrate to a new location since it should run on
older version of system due to APEX requirements.
For backward compatibility, instead of changing the value of old
variable, a new variable is added.
- VNDK_VER : "-" prefixed vndk version, used for older path
(e.g. /system/lib/vndk-sp-29)
- VNDK_APEX_VER : "v" prefixed vndk versions.
(e.g. /apex/com.android.vndk.v29/lib)
Test: add a vendor binary to /apex/com.android.media.swcodec/bin
which opens /system/lib/vndk-sp{VNDK_VER}/hw/android.hidl.memory@1.0-impl.so
via android_load_sphal_library()
Bug: 142912195
Change-Id: I3dfb3c1068cff00d5b63e92d51da6c4af00d264e
Linker config generator now covers ld.config.txt for Legacy and
VNDK-Lite devices, so linker can use those instead of existing ones
under /system/etc
Bug: 139638519
Test: m -j passed
Change-Id: I90f14727148cbf9629b90dc4fd78362bed8ea4e4
I plan to add tests to this test binary that take a long time to run.
The first is a malloc test that demonstrates that jemalloc appears
to be leaking memory slowly over time.
Test: Ran the bionic-stress-tests on host and verified it runs forever,
Test: but doesn't display RSS/VSS data.
Test: Ran the bionic-stress-tests on a taimen and verified it runs forever,
Test: and does display RSS/VSS data.
Change-Id: Ic612e4181ffea898d4d83af097939cd517a180ee
This relocation is labeled as a static relocation in the ARM ELF ABI and
shouldn't appear in position-independent code.
It currently calculates the value to relocate incorrectly:
"sym_addr - rel->r_offset" should be "sym_addr - reloc"
I don't know of any other dynamic linker that handles this relocation.
Test: bionic unit tests
Bug: http://b/19197129
Change-Id: Ia0c0018c82fe98d5edb54ee6f5c9f402b1fa3076
Combine:
- R_AARCH64_ABS64
- R_ARM_ABS32
- R_X86_64_64
- R_386_32
They do mostly the same thing as R_GENERIC_GLOB_DAT. They always have an
addend, though, and R_GENERIC_GLOB_DAT currently only has an addend on
RELA targets.
Test: bionic unit tests
Bug: none
Change-Id: Ibe964c3b28705086aecb6e7d80c90998aad3c0a4
Specifically, remove:
- R_AARCH64_ABS32
- R_AARCH64_ABS16
- R_AARCH64_PREL64
- R_AARCH64_PREL32
- R_AARCH64_PREL16
These relocations never currently appear in dynamic ELF files, and the
linker didn't handle them correctly. The AArch64 ELF ABI document
classifies them as "static relocations", which dynamic linkers don't need
to handle. (The document also classifies R_AARCH64_ABS64 as static,
though, and that relocation is common in DSOs. Perhaps static linkers
can't use R_AARCH64_GLOB_DAT to relocate data outside the GOT.)
Previously, for {ABS,PREL}{32,16}, Bionic always failed with an
out-of-range error. e.g. For {ABS,PREL}16, the value had to satisfy two
conditions:
- be at least (Elf64_Addr)INT16_MIN, i.e. 0xffff_ffff_ffff_8000
- be at most (Elf64_Addr)UINT16_MAX, i.e. 0xffff
The PREL relocations should have used sym_addr + addend - reloc, not
sym_addr + addend - rel->r_offset.
Bug: http://b/19197129
Test: bionic unit tests
Change-Id: I791da8ac471b3fb108cf77405c222f6e4bd34ae4
The description of memory_replay talks about unzippping the trace
files, but this is no longer necessary. This language has been
updated to reflect this.
Test: NA
Change-Id: Id808f9bd1286284c8de12b19c08eb8677c76dd53
The linker shouldn't throw exceptions, but because it links with
libc++_static.a, there are code paths that could throw an exception. On
those code paths, the unwinder needs to lookup EH information for the
linker binary, and the linker had two inconsistent ways of doing this:
* dl_iterate_phdr (for libgcc): dlfcn.cpp defined a linker-internal
version of this API that forwarded to __loader_dl_iterate_phdr
* __gnu_Unwind_Find_exidx (for arm32 libgcc): linker_exidx_static.c was
an old, broken copy of exidx_static.c that used
__exidx_start/__exidx_end symbols. (The file should have used the
addresses of the symbols rather than their contents.)
The linker's data structures might be in an inconsistent state at a point
where exceptions are thrown, so it seems better to limit its unwinder to
just the linker binary's EH info. Rather than forward the dl* EH APIs,
link in the static-binary versions from libc_unwind_static.a. That library
is already part of libc_nomalloc.a, but include it directly with
whole_static_libs so that __gnu_Unwind_Find_exidx is defined when we're
using libgcc on arm32.
Try to link in libunwind_llvm.a into the arm32 linker binary so we're
using the same unwinder as normal arm32 binaries. I'm not sure the library
will appear in the right order, but maybe it doesn't matter given LLD's
unconventional archive linking semantics.
Test: bionic unit tests
Test: "readelf --dyn-syms linker" reports no UNDEF symbols
Test: "readelf -r linker" reports only relative relocations
Bug: none
Change-Id: I5982ec830ba0f15d066536de24f6cd7e9503498b
Merged-In: I5982ec830ba0f15d066536de24f6cd7e9503498b
arm32 has two special APIs to find exidx exception handling info,
dl_unwind_find_exidx and __gnu_Unwind_Find_exdix. The two functions have
identical behavior and function prototypes. libgcc's arm32 unwinder calls
__gnu_Unwind_Find_exdix, whereas LLVM's libunwind previously called
__gnu_Unwind_Find_exdix, but switched to dl_unwind_find_exidx as a result
of three patches (D30306, D30681, D39468).
In Bionic, for dynamic linking, __gnu_Unwind_Find_exdix in libc.so calls
dl_unwind_find_exidx in libdl.so.
For static executables, though, __gnu_Unwind_Find_exdix in libc.a used the
__exidx_* symbols, while dl_unwind_find_exidx in libdl.a(libdl_static.o)
was a return-0 no-op.
To fix the LLVM unwinder, replace the no-op dl_unwind_find_exidx in
libdl.a with a real function in libc.a(exidx_static.o), and have the GNU
function call the dl function for more consistency with dynamic linking.
dl_iterate_phdr follows a similar pattern, where the function exists in
libc.a and libdl.so (not libc.so or libdl.a).
This change makes unwinding work with an updated libunwind_llvm on arm32,
and it helps to allow unwinding in static executables without libdl.a.
Bug: https://github.com/android/ndk/issues/1094
Bug: http://b/141485154
Test: NDK tests, bionic unit tests
Change-Id: Ieeeb9b39a0e28544e21f9afe6fe51ef10d7c828c
With VNDK APEX, the path for VNDK libs has been changed
from /system/lib/vndk-VER to /apex/com.android.vndk.vVER/lib
Previously, VNDK_VER is replaced with prefix(e.g. "-29"). We could
still prepend prefix("v") to the vndk version, but this change uses a
raw vndk version as the value of VNKD_VER.
Bug: 141451661
Test: m && boot (tested with cuttlefish)
Change-Id: Ibf4cf5e29b7f28e733d4b3bc15171f4359e1d2f2
Scudo creates a large map on 64 bit which can cause a slow down trying
to get the usage stats for all maps. Since the test only really cares
about a small subset of maps, only get the usage stats for those maps.
Test: Ran unit tests on scudo and jemalloc based systems.
Change-Id: Iba3cff1487ca304083aac323a3971b9f939f5c11
As the first pass, the malloc_info for scudo doesn't return anything.
This feature is hardly ever used, so this seems fine for the first
revision.
Bug: 137795072
Test: Ran unit tests on a taimen using scudo and a taimen using jemalloc.
Change-Id: I675386ae17ba5505c27bd9da12c60242d795464a
