This reverts commit 8dba7fefb0.
Reason for revert: This workaround is not necessary with ag/10700799
Merged-In: I2bf469bfe00f3a70e67085abfb3822db6908d522
Change-Id: If351aedfce23d60582f0c5ff965f94356d1900d9
Bug: 150860940
When libbase is built for an APEX, it uses dlsym to reflectively access
liblog symbols that are added in R. This is because the APEX where
libbasse is packaged into might be running in pre-R devices where the
symbols don't exist in liblog.so.
This however causes a problem for a static executable in an APEX. Since
it is in an APEX, the dlsym is used. But libdl.so which provides dlsym
is not available to static executable. Currently, the dynamic linker is
the only executable in an APEX that all of its dependencies are
statically linked. Fixing the issue by providing fake dlsym by
statically linking to libdl.a.
Exempt-From-Owner-Approval: cherry-pick rvc-dev
Bug: 149569129
Test: m
Merged-In: I2e9e45d9876c2d6c878e541715389e6d1ef56996
(cherry picked from commit ec829ed4ea)
Change-Id: I2e9e45d9876c2d6c878e541715389e6d1ef56996
XOM is no longer supported by the build system, so remove these
properties.
Bug: 123034666
Bug: 147300048
Test: Build succeeds.
Change-Id: I77efc98241f45b1a78b1cca5560f64eef5ef22f4
Symbol lookup is O(L) where L is the number of libraries to search (e.g.
in the global and local lookup groups). Factor out the per-DSO work into
soinfo_do_lookup_impl, and optimize for the situation where all the DSOs
are using DT_GNU_HASH (rather than SysV hashes).
To load a set of libraries, the loader first constructs an auxiliary list
of libraries (SymbolLookupList, containing SymbolLookupLib objects). The
SymbolLookupList is reused for each DSO in a load group. (-Bsymbolic is
accommodated by modifying the SymbolLookupLib at the front of the list.)
To search for a symbol, soinfo_do_lookup_impl has a small loop that first
scans a vector of GNU bloom filters looking for a possible match.
There was a slight improvement from templatizing soinfo_do_lookup_impl
and skipping the does-this-DSO-lack-GNU-hash check.
Rewrite the relocation processing loop to be faster. There are specialized
functions that handle the expected relocation types in normal relocation
sections and in PLT relocation sections.
This CL can reduce the initial link time of large programs by around
40-50% (e.g. audioserver, cameraserver, etc). On the linker relocation
benchmark (64-bit walleye), it reduces the time from 131.6ms to 71.9ms.
Bug: http://b/143577578 (incidentally fixed by this CL)
Test: bionic-unit-tests
Change-Id: If40a42fb6ff566570f7280b71d58f7fa290b9343
This supports the soong commit which causes most platform binaries to stop
statically linking against the unwinder implementation. The soong commit
message has more motivation for this change.
ARM32 uses LLVM libunwind, while all other platforms use libgcc as the
unwinder implementation. This matches the current choices of unwinders on
the various architectures, but means that apps which were directly linking
against the libc.so unwinder symbols on ARM32 are now using LLVM libunwind
instead of libgcc.
Set libc_headers sdk_version to 1 so that libunwind_llvm can depend on it,
and stop statically linking libunwind into libc_malloc_debug.
Bug: 144430859
Change-Id: I52c7f7893d93f500383aeb0b76086c3b6f1935a5
A later linker CL defines a function that needs to forward a printf format
and argument list to TRACE(), but there is no version of the TRACE macro
that works with a va_list. The CL also needs to check the verbosity level,
using a slow path if tracing is enabled, so define LINKER_VERBOSITY_xxx
macros.
Bug: none
Test: bionic unit tests
Change-Id: I578d36a12dc40f9a651956b4b09adc1a7c644e24
The string is still "lib" or "lib64" with native bridge. It doesn't need
to be configured in the Android.bp file anymore, so move it to a header
file. This change will ensure that ${LIB} expands to the same thing in
both ld.config.txt and DT_RUN_PATH.
Bug: http://b/145197367
Test: manual
Change-Id: Iab87f3156f2984dd3a20e4ccda423892c8b58763
Merged-In: Iab87f3156f2984dd3a20e4ccda423892c8b58763
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)
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
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
As of aosp/1086558, stdatomic.h directly checks for the presence of
<atomic> instead of checking _USING_LIBCXX, so these lines are
obsolete.
Test: build
Change-Id: Icfdb47b3ad109421b3413041f3d3027e2c0b518e
The demangler is moving out of libc++abi to save on bloat.
Test: make checkbuild
Bug: http://b/138245375
Change-Id: I7402894bb326f524388c9efdf86509dad50f2018
Given that we have both linker and linker64, I didn't really want to have
to have ldd and ldd64, so this change just adds the --list option to the
linkers and a shell script wrapper "ldd" that calls the appropriate
linker behind the scenes.
Test: adb shell linker --list `which app_process32`
Test: adb shell linker64 --list `which date`
Test: adb shell ldd `which app_process32`
Test: adb shell ldd `which date`
Change-Id: I33494bda1cc3cafee54e091f97c0f2ae52d1f74b
Enable native bridge support for bionic libraries.
Makes it possible to use them in binaries for translated
architectures.
Bug: http://b/77159578
Test: make
Change-Id: Iccd4ad7aecfa5260cc15f09ca975d2e18987278a
The *.mountpoint targets that installs /bionic/lib/lib*.so and
/bionic/bin/linker* are no longer needed.
Now, /system/lib/lib*.so and /system/bin/linker* are simply symlinks to
the corresponding files in the runtime apex. For example,
/system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
This is made possible because we now activate APEXes even before the
data partition is mounted. Before the data partition mounting, the
APEXes from the system partition are ativated. After the data partition
is mounted, updated APEXes in the partition (if any) are activated. As a
result, the symlink always points to the valid path regardless of
whether /data is mounted or not.
Bug: 125549215
Test: device boots
Change-Id: Ie7d83686abe00b3c436f9f9db75d4244200a0fc9
Life is easier if we just keep test code in the same directory as the
stuff it's testing...
Test: tests still build and pass
Change-Id: I9b35d689098bdc28a71d69645b0ca9fdd6ea0108
Bug: http://b/116873221
The coverage library, which depends on libc, cannot link with libraries
since they opt of libc.
Test: m NATIVE_COVERAGE=true COVERAGE_PATHS=bionic
Change-Id: Iaaca8bc30c8ba59e5d4f7092b1a0fce8e8c14c72
The dynamic linker installed to /system partition is only for
bootstraping, i.e. to be used only by early processes. The existing path
/system/bin/linker[64] will be a symlink to the mount pointpoint
/bionic/bin/linker[64] which will be bind-mounted with either the
bootstrap linker or the default linker in the runtime APEX. Since the
path is taken by the symlink, bootstrap linker is moved to ./boostrap
subdirectory.
Bug: 120266448
Test: m linker; the linker is found under /system/bin/bootstrap/
Change-Id: I163e0c8a1738b94565a6b60f48e65841ba058a91
This change adds following files and symlinks:
Files:
/bionic/lib[64]/lib{c|dl|m}.so
/bionic/bin/linker[64]
Symlinks:
/system/lib[64]/lib{c|dl|m}.so -> /bionic/lib[64]/lib{c|dl|m}.so
/system/bin/linker[64] -> /bionic/bin/linker[64]
/system/bin/linker_asan[64] -> /bionic/bin/linker[64]
The files serve as mount points for either the bootstrap Bionic or the
default Bionic from the runtime APEX. init does the bind-mounting during
booting.
The symlinks are there to not change the ordinary paths to the bionic
files; there are many places that the paths are implied or hard-coded,
e.g., dlopen("/system/lib/libc.so") or DT_INTERP pointing to
/system/bin/linker in the vendor prebuilts.
Bug: 120266448
Test: m blueline, cf_x86, aosp_arm
The aforementioned files and symlinks are found
Change-Id: I97e38c29409ac0610dde285db8df6e94a7930094
Each TLSDESC relocation relocates a 2-word descriptor in the GOT that
contains:
- the address of a TLS resolver function
- an argument to pass (indirectly) to the resolver function
(Specifically, the address of the 2-word descriptor is passed to the
resolver.)
The loader resolves R_GENERIC_TLSDESC relocations using one of three
resolver functions that it defines:
- tlsdesc_resolver_static
- tlsdesc_resolver_dynamic
- tlsdesc_resolver_unresolved_weak
The resolver functions are written in assembly because they have a
restrictive calling convention. They're only allowed to modify x0 and
(apparently) the condition codes.
For a relocation to memory in static TLS (i.e. the executable or an solib
loaded initially), the loader uses a simple resolver function,
tlsdesc_resolver_static, that returns the static offset it receives from
the loader.
For relocations to dynamic TLS memory (i.e. memory in a dlopen'ed solib),
the loader uses tlsdesc_resolver_dynamic, which allocates TLS memory on
demand. It inlines the fast path of __tls_get_addr, then falls back to
__tls_get_addr when it needs to allocate memory. The loader handles these
dynamic TLS relocations in two passes:
- In the first pass, it allocates a table of TlsDynamicResolverArg
objects, one per dynamic TLSDESC relocation.
- In the second pass, once the table is finalized, it writes the
addresses of the TlsDynamicResolverArg objects into the TLSDESC
relocations.
tlsdesc_resolver_unresolved_weak returns a negated thread pointer so that
taking the address of an unresolved weak TLS symbols produces NULL.
The loader handles R_GENERIC_TLSDESC in a target-independent way, but
only for arm64, because Bionic has only implemented the resolver functions
for arm64.
Bug: http://b/78026329
Test: bionic unit tests
Test: check that backtrace works inside a resolver function and inside
__tls_get_addr called from a resolver
(gdbclient.py, b __tls_get_addr, bt)
Merged-In: I752e59ff986292449892c449dad2546e6f0ff7b6
Change-Id: I752e59ff986292449892c449dad2546e6f0ff7b6
Rename LinkerMemoryAllocator -> BionicAllocator
Rename LinkerSmallObjectAllocator -> BionicSmallObjectAllocator
libc and the linker need to share an instance of the allocator for
allocating and freeing dynamic ELF TLS memory (DTVs and segments). The
linker also continues to use this allocator.
Bug: http://b/78026329
Test: /data/nativetest/bionic-unit-tests-static
Test: /data/nativetest64/bionic-unit-tests-static
Test: /data/nativetest/linker-unit-tests/linker-unit-tests32
Test: /data/nativetest64/linker-unit-tests/linker-unit-tests64
Change-Id: I2da037006ddf8041a75f3eba2071a8fcdcc223ce
In addition to ORIGIN, LIB is now expanded to either lib or lib64
depending on the ABI in the DT_RUNPATH.
Test: To be added (can't be added to AOSP directly since there are
internal tests that have to be updated as well)
Change-Id: I34a8316f1765a27c731bc270ee25c0ce287d7eed
This macro is necessary for using stdatomic.h and <atomic> in the same
libc++-based program. <atomic> is used implicitly by other STL headers,
and stdatomic.h is used (or will be used) in headers shared with libc.
libc only has access to stdatomic.h because it can't use an STL.
Bug: http://b/78026329
Test: bionic unit tests
Change-Id: I89b128df08b478287ef4e2867319e74dbcc30d4e
For ELF TLS "local-exec" accesses, the static linker assumes that an
executable's TLS segment is located at a statically-known offset from the
thread pointer (i.e. "variant 1" for ARM and "variant 2" for x86).
Because these layouts are incompatible, Bionic generally needs to allocate
its TLS slots differently between different architectures.
To allow per-architecture TLS slots:
- Replace the TLS_SLOT_xxx enumerators with macros. New ARM slots are
generally negative, while new x86 slots are generally positive.
- Define a bionic_tcb struct that provides two things:
- a void* raw_slots_storage[BIONIC_TLS_SLOTS] field
- an inline accessor function: void*& tls_slot(size_t tpindex);
For ELF TLS, it's necessary to allocate a temporary TCB (i.e. TLS slots),
because the runtime linker doesn't know how large the static TLS area is
until after it has loaded all of the initial solibs.
To accommodate Golang, it's necessary to allocate the pthread keys at a
fixed, small, positive offset from the thread pointer.
This CL moves the pthread keys into bionic_tls, then allocates a single
mapping per thread that looks like so:
- stack guard
- stack [omitted for main thread and with pthread_attr_setstack]
- static TLS:
- bionic_tcb [exec TLS will either precede or succeed the TCB]
- bionic_tls [prefixed by the pthread keys]
- [solib TLS segments will be placed here]
- guard page
As before, if the new mapping includes a stack, the pthread_internal_t
is allocated on it.
At startup, Bionic allocates a temporary bionic_tcb object on the stack,
then allocates a temporary bionic_tls object using mmap. This mmap is
delayed because the linker can't currently call async_safe_fatal() before
relocating itself.
Later, Bionic allocates a stack-less thread mapping for the main thread,
and copies slots from the temporary TCB to the new TCB.
(See *::copy_from_bootstrap methods.)
Bug: http://b/78026329
Test: bionic unit tests
Test: verify that a Golang app still works
Test: verify that a Golang app crashes if bionic_{tls,tcb} are swapped
Merged-In: I6543063752f4ec8ef6dc9c7f2a06ce2a18fc5af3
Change-Id: I6543063752f4ec8ef6dc9c7f2a06ce2a18fc5af3
(cherry picked from commit 1e660b70da)
It was discovered that we were building some objects inconsistently due
to an optimization in cc_library to only build objects once and use them
for both the static and shared libraries. But static libraries didn't
get system_shared_libs set automatically, and we didn't notice that we
would have built the objects differently.
So static libraries now get the default system_shared_libs, we allow
adjusting that for static vs shared in a cc_library, and we disable the
optimization if the linked libraries are configured differently between
static and shared in a single cc_library.
This triggers dependency cycles for static libraries that libc/libdl
use, so fix those cycles here.
Test: treehugger
Change-Id: I3cf7fda161a05ec32e0c1e871999720d12a4d38e
These modules have issues running with execute-only memory. Disable it
in them until we can resolve the issues.
Bug: 77958880
Test: No more XOM-related crashes in these binaries
Change-Id: Ie6c957731155566c2bbe7dbb7a91b9583d9aff93
This reverts commit 73de62e461.
Reason for revert: bug was fixed upstream and included into AOSP lld
Bug: 78115263
Test: make checkbuild
Change-Id: Ib9e4af1efdcdb547c7bd65cce4ce48d7f09ed217
Use <android-base/macros.h> instead where possible, and move the bionic
macros out of the way of the libbase ones. Yes, there are folks who manage
to end up with both included at once (thanks OpenGL!), and cleaning that
up doesn't seem nearly as practical as just making this change.
Bug: N/A
Test: builds
Change-Id: I23fc544f39d5addf81dc61471771a5438778895b
Move source files to filegroup and extract c/ldflags and
version-script to linker_defaults.
Bug: http://b/71494052
Test: make
Change-Id: Ic82885e1c006f91a8446978fabd214f87cd20510
* Allow sanitization of libc (excluding existing global sanitizers)
and disallow sanitization of linker. The latter has not been
necessary before because HWASan is the first sanitizer to support
static binaries (with the exception of CFI, which is not used
globally).
* Static binary startup: initialize HWASan shadow very early so that
almost entire libc can be sanitized. The rest of initialization is
done in a global constructor; until that is done sanitized code can
run but can't report errors (will simply crash with SIGTRAP).
* Switch malloc_common from je_* to __sanitizer_*.
* Call hwasan functions when entering and leaving threads. We can not
intercept pthread_create when libc depends on libclang_rt.hwasan.
An alternative to this would be a callback interface like requested
here:
https://sourceware.org/glibc/wiki/ThreadPropertiesAPI
All of the above is behind a compile-time check
__has_feature(hwaddress_sanitizer). This means that HWASan actually
requires libc to be instrumented, and would not work otherwise. It's
an implementation choice that greatly reduces complexity of the tool.
Instrumented libc also guarantees that hwasan is present and
initialized in every process, which allows piecemeal sanitization
(i.e. library w/o main executable, or even individual static
libraries), unlike ASan.
Change-Id: If44c46b79b15049d1745ba46ec910ae4f355d19c
In order to support shared libraries in the recovery mode, the dynamic
linker is now built with recovery_available: true option.
In addition, a few more modules (such as libasync, etc.) are also marked
as recovery_available: true as they are transitive dependencies of the
dynamic linker.
Bug: 63673171
Test: `adb reboot recovery; adb devices` shows the device ID
Test: `adb root && adb shell` and then
$ lsof -p `pidof adbd` shows that libm.so, libc.so, etc. are loaded from
the /lib directory.
Change-Id: Idd981d8cf25568a85b24032cf78e50adfd5f4a7f
Libraries that are direct or indirect dependencies of modules installed
to recovery partition (e.g. toybox) are marked as recovery_available:
true. This allows a recovery variant of the lib is created when it is
depended by other recovery or recovery_available modules.
Bug: 67916654
Bug: 64960723
Bug: 63673171
Bug: 29921292
Test: m -j
Change-Id: I59bf859a10a218af6591025a0fe7d1853e328405
* Specify "nocrt: true" to avoid calling __cxa_finalize.
* Define a dummy __aeabi_unwind_cpp_pr0 for arm32.
Bug: b/62815515
Bug: b/73873002
Test: boot AOSP hikey960-userdebug
Test: run ndk_cxa_example in special /system/bin/debug namespace
Test: run Bionic unit tests
Change-Id: I59bcb100a2753286b59c51a47d7a183507219a07
