With -O0, on arm64, Clang uses memset for this declaration:
bionic_tcb temp_tcb = {};
arm64 doesn't currently have an ifunc for memset, but if it did, then this
line would crash when the linker is compiled with -O0. It looks like other
architectures would only use a memset call if the bionic_tcb struct were
larger.
Avoid memset by using a custom memclr function that the compiler optimizes
into something efficient.
Also add __attribute__((uninitialized)) to ensure that
-ftrivial-auto-var-init does not generate a call to memset. See this
change[1] in build/soong.
[1] If085ec53c619e2cebc86ca23f7039298160d99ae
Test: build linker with -O0, linker[64] --help works
Bug: none
Change-Id: I0df8065a362646de4fa021cae63a7d68ca3966b6
This change makes it easier to diagnose mistakes in linker
configuration that result in a library being accidentally loaded in
multiple namespaces without its dependencies available everywhere.
Test: manually tested the error message
Test: bionic-unit-tests
Change-Id: I03a20507f8fc902c2445a7fbbf59767ffffd5ebf
Using ifuncs allows the linker to select faster versions of libc functions
like strcmp, making linking faster.
The linker continues to first initialize TLS, then call the ifunc
resolvers. There are small amounts of code in Bionic that need to avoid
calling functions selected using ifuncs (generally string.h APIs). I've
tried to compile those pieces with -ffreestanding. Maybe it's unnecessary,
but maybe it could help avoid compiler-inserted memset calls, and maybe
it will be useful later on.
The ifuncs are called in a special early pass using special
__rel[a]_iplt_start / __rel[a]_iplt_end symbols. The linker will encounter
the ifuncs again as R_*_IRELATIVE dynamic relocations, so they're skipped
on the second pass.
Break linker_main.cpp into its own liblinker_main library so it can be
compiled with -ffreestanding.
On walleye, this change fixes a recent 2.3% linker64 start-up time
regression (156.6ms -> 160.2ms), but it also helps the 32-bit time by
about 1.9% on the same benchmark. I'm measuring the run-time using a
synthetic benchmark based on loading libandroid_servers.so.
Test: bionic unit tests, manual benchmarking
Bug: none
Merged-In: Ieb9446c2df13a66fc0d377596756becad0af6995
Change-Id: Ieb9446c2df13a66fc0d377596756becad0af6995
(cherry picked from commit 772bcbb0c2)
Define a "linker_bin_template" cc_defaults module that a native bridge
implementation can inherit to define a guest linker.
Break the debuggerd_init call off into separate
linker_debuggerd_{android,stub}.cpp files to allow opting in/out of the
debuggerd integration without needing to change how linker_main.cpp is
compiled. (This is necessary for a later commit that moves
linker_main.cpp into a new static library.)
Test: bionic unit tests
Bug: none
Merged-In: I7c5d79281bce1e69817b266dd91d43ea40f78522
Change-Id: I7c5d79281bce1e69817b266dd91d43ea40f78522
(cherry picked from commit 5adf402ee9)
This reverts commit 61a97e9505.
Reason for revert: Breaks ART run-tests (b/143458513).
Test: Run ART tests on device in a chroot environment
Bug: 143458513
Bug: 139638519
Change-Id: Ib047a24d6e82e38ebdaafeab294b8be44b74bd9c
In order for an ifunc resolver to detect the presence of certain CPU features,
access to getauxval(AT_HWCAP) or getauxval(AT_HWCAP2) may be required. In order
for getauxval() to work, it needs to access the pointer to the auxiliary vector
stored by the linker in the libc shared globals data structure. Accessing the
shared globals requires libc to call the __libc_shared_globals() function
exported by the linker. However, in order to call this function, libc must
be fully relocated, which is not guaranteed to be the case at the point when
ifunc resolvers are called.
glibc solves this problem by passing the values of getauxval(AT_HWCAP)
(and getauxval(AT_HWCAP2) on aarch64) as arguments to the ifunc resolver.
Since this seems to be not only the most straightforward way to solve the
problem but also improves our compatibility with glibc, we adopt their
calling convention.
This change is ABI compatible with old resolvers because the arguments are
passed in registers, so the old resolvers will simply ignore the new arguments.
Bug: 135772972
Change-Id: Ie65bd6e7067f0c878df3d348c815fda61dc12de2
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
COUNT_PAGES tries to count the pages dirtied by relocations, but this
implementation is broken because it's merging rel->r_offset values from
multiple DSOs. The functionality is hard to use, because it requires
rebuilding the linker, and it's not obvious to me that it should belong
in the linker. If we do want it, we should make it work without rebuilding
the linker.
Similar information can currently be collected by parsing the result of
`readelf -r` on a binary (or a set of binaries).
Bug: none
Test: m linker libc com.android.runtime ; adb sync ; run something
Change-Id: I760fb6ea4ea3d1927eb5145cdf4ca133851d69b4
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
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 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
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
The bionic libs are now restricted to be in the runtime APEX and the
platform (for bootstrapping). It can still be referenced from other
APEXes but can't be included there.
Bug: 139870423
Test: m
Change-Id: I7f99eef27ccf75844ca5c9a7ea866496841b738f
The run-time of dl_iterate_phdr can be noticeable for exception-handling.
e.g. I tested extest on the GitHub issue by:
- disabling the dlpi_subs/dlpi_adds-based caching in libgcc
- adding a weaker "load base hint" caching in libgcc that doesn't need
the dlpi_subs/dlpi_adds fields, but still has to iterate over every
module to validate a cache hit
extest throws 10000 exceptions, and I saw a regression from ~1550ms
runtime on Q to about ~1950ms on master. This CL reduces the regression to
about ~1700ms.
Bug: https://github.com/android/ndk/issues/1062
Test: bionic unit tests
Change-Id: I099e97e1a20f5b2aa6737789e49d965170eb85a8
There are places in frameworks and art code that directly included
private bionic header files. Move these files to the new platform
include files.
This change also moves the __get_tls.h header file to tls.h and includes
the tls defines header so that there is a single header that platform
code can use to get __get_tls and the defines.
Also, simplify the visibility rules for platform includes.
Bug: 141560639
Test: Builds and bionic unit tests pass.
Change-Id: I9e5e9c33fe8a85260f69823468bc9d340ab7a1f9
Merged-In: I9e5e9c33fe8a85260f69823468bc9d340ab7a1f9
(cherry picked from commit 44631c919a)
Use generated linker config by default, but with some back up plan
(sys.linker.use_generated_config property). Linker config generator
still does not support non-treblelized devices and vndk-lite, so these
cases should be handled later.
Bug: 138920271
Test: m -j && atest passed
Test: Tested from cuttlefish
Change-Id: I39e9d089a82f9409eccdcaa4fb26660caf3f5779
Main change is to log errors directly where they occur, to correlate with
other dlopen/dlsym logs.
Test: Build & boot with and without LinkerLogger::flags_ initialised to kLogDlopen
Change-Id: If36f52914dc97cedd95dc9375c291640c6891728
This reverts commit 39699ea095.
Reason for revert: This breaks swcodec apex. (It still uses VNDK_VER)
Bug: 140014331
Change-Id: I3a4c5b68fdd5e42fdf93c4c71f6c3be839ea8a28
Previously, Bionic's dl_phdr_info only included the first four
dl_iterate_phdr fields. Several other libc's have these additional fields:
unsigned long long dlpi_adds -- incremented when a library is loaded
unsigned long long dlpi_subs -- incremented when a library is unloaded
size_t dlpi_tls_modid -- TLS module ID
void* dlpi_tls_data -- pointer to current thread's TLS block or NULL
These extra fields are also exposed by glibc, musl, and FreeBSD. The
unwinder in libgcc.a, linked into shipping Android DSOs, has a
PC->eh_frame cache that activates if dl_phdr_info has the dlpi_adds and
dlpi_subs fields (indicated at run-time by a sufficiently-large size
argument to the callback).
Bug: https://github.com/android-ndk/ndk/issues/1062
Test: bionic unit tests
Change-Id: I6f0bab548cf8c828af2ddab9eb01c5c6d70cd81f
The call to the load hook needs to be moved before the call to link_image()
because the latter calls ifunc resolvers which might access global
variables. This fixes a bunch of ifunc tests.
The dlfcn.segment_gap test is currently failing. One problem is that the name
of the .bss.end_of_gap section changes as a result of global instrumentation.
Add some wildcards in so that we match both names. The other problem seems
to be the same as b/139089152.
It turns out that we need to untag pointers in a few more places. Since we have
quite a few of these now it seems worth creating a function for it.
Test: bionic-unit-tests
Change-Id: I44e2b0904faacdda7cc0c5e844ffc09de01dea2d
The linker currently sets VMA name ".bss" for bss sections in DSOs
loaded by the linker. With this change, the linker now also sets VMA
name for bss sections in the linker itself and the main executable, so
that they don't get left out in various accounting.
Test: Run 'dd' and check its /proc/<pid>/maps.
Change-Id: I62d9996ab256f46e2d82cac581c17fa94836a228
This reverts commit 66b5e3ca19.
Reason for revert: Causes installd_dexopt_test to fail. Presumably there is an existing issue which this change is turning into a hard fail, so that needs to be fixed before this can be rolled forwards. See b/139092341.
Bug: 139092341
Bug: 137788030
Change-Id: I1beccddff64c86541bc003b9b009f4046ec9cbf1
Anonymous namespace is not created separately. When a regular namespace
is created with ANDROID_NAMESPACE_TYPE_ALSO_USED_AS_ANONYMOUS, that
namespace is used as the anonymous namespace.
Bug: 130388701
Test: CtsBionicTestCases
Change-Id: Ie449a59f303487a7a9ff6fff98e6148e9f968fd2
