Auto-generate NOTICE files for all the directories, and for each one
individually rather than mixing libc and libm together.
Test: N/A
Change-Id: I7e251194a8805c4ca78fcc5675c3321bcd5abf0a
With this change we can report memory errors involving secondary
allocations. Update the existing crasher tests to also test
UAF/overflow/underflow on allocations with sizes sufficient to trigger
the secondary allocator.
Bug: 135772972
Change-Id: Ic8925c1f18621a8f272e26d5630e5d11d6d34d38
These lines shouldn't actually matter, because the DSOs are using
version scripts to allow-list exported symbols.
Bug: none
Test: bionic unit tests
Change-Id: I39d3df8c4f8053624f862b3c6994e30c693e928c
During "step 1" of find_libraries, the linker finds the transitive
closure of dependencies, in BFS order. As it finds each library, it
adds the library to its primary namespace (so that, if some other
library also depends on it, find_loaded_library_by_soname can find the
library in the process of being loaded).
LD_PRELOAD libraries are automatically marked DF_1_GLOBAL, and any
DF_1_GLOBAL library is added to every linker namespace. Previously,
this secondary namespace registration happened after step 1. The result
is that across different namespaces, the order of libraries could vary.
In general, a namespace's primary members will all appear before
secondary members. This is undesirable for libsigchain.so, which we
want to have appear before any other non-preloaded library.
Instead, when an soinfo is added to its primary namespace, immediately
add it to all the other namespaces, too. This ensures that the order of
soinfo objects is the same across namespaces.
Expand the dl.exec_with_ld_config_file_with_ld_preload and
dl.exec_with_ld_config_file tests to cover the new behavior. Mark
lib1.so DF_1_GLOBAL and use a "foo" symbol to mimic the behavior of a
signal API interposed by (e.g.) libsigchain.so and a ASAN preload.
Test: bionic unit tests
Bug: http://b/143219447
Change-Id: I9fd90f6f0d14caf1aca6d414b3e9aab77deca3ff
No-one seems to understand that a crash in a random .so from call_array()
in the linker isn't a linker bug. They _seem_ to understand (or at least
claim to) when we explain that this is just the linker calling their ELF
constructors --- despite the fact that the caller of call_array() is
call_constructors().
One experiment we can try though is to inline call_array() to elide that
frame from the crash dumps. I do also wonder whether renaming
call_constructors() to call_elf_constructors() would help/hinder/make no
difference. For now I'm leaning toward "hinder" because I suspect most
people don't understand "ELF constructor" and C++ folks at least will
probably be influenced in a not wholly incorrect direction when they
hear "constructor" (whereas "ELF constructor" might mislead them back in
the direction of "strange linker magic, not my fault" again)...
(The reformatting is clang-format's decision, not mine.)
Test: treehugger
Change-Id: I65ab95ceb2e988fd053c48c66f51afba17ccfa61
For libc.so, use a special build of libunwind.a whose symbols aren't
hidden ("libunwind-exported"), because libc.so exports the _Unwind_*
APIs.
Bug: http://b/153025717
Test: bionic unit tests
Change-Id: I7435e076ec8cc4410e3e6086d3cf5d2c6011c80c
Setting the linker's soname ("ld-android.so") can allocate heap memory
now that the name uses an std::string, and it's probably a good idea to
defer doing this until after the linker has relocated itself (and after
it has called C++ constructors for global variables.)
Bug: none
Test: bionic unit tests
Test: verify that dlopen("ld-android.so", RTLD_NOLOAD) works
Change-Id: I6b9bd7552c3ae9b77e3ee9e2a98b069b8eef25ca
Once upon a time (and, indeed, to this very day if you're on LP32) the
soinfo struct used a fixed-length buffer for the soname. This caused
some issues, mainly with app developers who accidentally included a full
Windows "C:\My Computer\...\libfoo.so" style path. To avoid all this we
switched to just pointing into the ELF file itself, where the DT_SONAME
is already stored as a NUL-terminated string. And all was well for many
years.
Now though, we've seen a bunch of slow startup traces from dogfood where
`dlopen("libnativebridge.so")` in a cold start takes 125-200ms on a recent
device, despite no IO contention. Even though libnativebridge.so is only
20KiB.
Measurement showed that every library whose soname we check required
pulling in a whole page just for the (usually) very short string. Worse,
there's readahead. In one trace we saw 18 pages of libhwui.so pulled
in just for `"libhwui.so\0"`. In fact, there were 3306 pages (~13MiB)
added to the page cache during `dlopen("libnativebridge.so")`. 13MiB for
a 20KiB shared library!
This is the obvious change to use a std::string to copy the sonames
instead. This will dirty slightly more memory, but massively improve
locality.
Testing with the same pathological setup took `dlopen("libnativebridge.so")`
down from 192ms to 819us.
Bug: http://b/177102905
Test: tested with a pathologically modified kernel
Change-Id: I33837f4706adc25f93c6fa6013e8ba970911dfb9
Use a note in executables to specify
(none|sync|async) heap tagging level. To be extended with (heap x stack x
globals) in the future. A missing note disables all tagging.
Bug: b/135772972
Test: bionic-unit-tests (in a future change)
Change-Id: Iab145a922c7abe24cdce17323f9e0c1063cc1321
There are multiple build breakages with bionic when we enable ThinLTO
globally. Opt bionic out of ThinLTO for now.
#global-thinlto-opt-out
Test: TreeHugger
Bug: 169004486
Change-Id: I546a8074f9c3e0ddbd01d3b7cd730e215e3c0c49
This patch adds support to load BTI-enabled objects.
According to the ABI, BTI is recorded in the .note.gnu.property section.
The new parser evaluates the property section, if exists.
It searches for .note section with NT_GNU_PROPERTY_TYPE_0.
Once found it tries to find GNU_PROPERTY_AARCH64_FEATURE_1_AND.
The results are cached.
The main change in linker is when protection of loaded ranges gets
applied. When BTI is requested and the platform also supports it
the prot flags have to be amended with PROT_BTI for executable ranges.
Failing to add PROT_BTI flag would disable BTI protection.
Moreover, adding the new PROT flag for shared objects without BTI
compatibility would break applications.
Kernel does not add PROT_BTI to a loaded ELF which has interpreter.
Linker handles this case too.
Test: 1. Flame boots
2. Tested on FVP with BTI enabled
Change-Id: Iafdf223b74c6e75d9f17ca90500e6fe42c4c1218
As we enable arm64-based Bionic host target (linux_bionic_arm64),
linker_wrapper is added with the corresponding source.
Bug: 159685774
Test: HOST_CROSS_OS=linux_bionic HOST_CROSS_ARCH=arm64 m
Test: copy out/soong/host/linux_bionic_arm64/ to an ARM64 emulator
running Linux and execute the binaries
Change-Id: I4f367a349f7e0015318352cb7f2870fc856eab05
(Based on proposal at https://sourceware.org/glibc/wiki/ThreadPropertiesAPI)
This includes API to:
- locate static and dynamic TLS
- register thread-exit and dynamic TLS creation/destruction callbacks
Change-Id: Icd9d29a5b2f47495395645e19d3b2c96826f19c8
Update a comment in android-changes-for-ndk-developers.md about the
removed debug.ld.greylist_disabled system property.
Update language to comply with Android's inclusive language guidance
#inclusivefixit
See https://source.android.com/setup/contribute/respectful-code for reference
Bug: http://b/162536543
Test: bionic-unit-tests
Change-Id: I760ee14bce14d9d799926c43d2c14fd8ffbc6968
1. Cleanup for #inclusivefixit. (whitelisted -> allowed_libs)
2. Support the old term for backwards compatibility. (Also update test.)
3. Fix the formatting errors found by clang-format.
See https://source.android.com/setup/contribute/respectful-code
for reference.
Bug: 161896447
Test: atest linker-unit-tests linker-benchmarks
Change-Id: I19dbed27a6d874ac0049cb7b67d2cb0f75369c1b
This property provided a way to disable the greylist, for testing
whether an app targeting < 24 still works. Instead of turning off the
greylist, though, an app developer should simply target a newer API.
(If app developers really need this property for testing, they can
still use it on versions of Android between N and R, inclusive.)
Update language to comply with Android's inclusive language guidance
See https://source.android.com/setup/contribute/respectful-code for reference
#inclusivefixit
Bug: http://b/162536543
Test: bionic-unit-tests
Change-Id: Id1eb2807fbb7436dc9ed7fe47e15b7d165a26789
Add inaccessible gaps between shared libraries to make it harder for the
attackers to defeat ASLR by random probing.
To avoid excessive page table bloat, only do this when a library is
about to cross a huge page boundary, effectively allowing several
smaller libraries to be lumped together.
Bug: 158113540
Test: look at /proc/$$/maps
Change-Id: I39c0100b81f72447e8b3c6faafa561111492bf8c
This reverts commit a8cf3fef2a.
Reason for revert: memory regression due to the fragmentation of the page tables
Bug: 159810641
Bug: 158113540
Change-Id: I6212c623ff440c7f6889f0a1e82cf7a96200a411
There are some special cases - such as init process - when linker
configuration is not expected to exist. This change disables warning
message that generated linker configuration does not exist in those
cases.
Bug: 158800902
Test: Tested from cuttlefish that warning message is not generated from
init
Change-Id: Ie2fbb5210175cf1e6f2b7e638f57c3b74d395368
Improve ASLR by increasing the randomly sized gaps between shared
library mappings, and keep them mapped PROT_NONE.
Bug: 158113540
Test: look at /proc/$$/maps
Change-Id: Ie72c84047fb624fe2ac8b7744b2a2d0d255ea974
This replaces a single 2Gb readable memory region with a bunch of tiny
regions, and leaves the bulk of 2Gb mapped but unaccessible. This makes
it harder to defeat ASLR by probing for the CFI shadow region.
Sample CFI shadow mapping with this change:
7165151000-716541f000 ---p 00000000 00:00 0 [anon:cfi shadow]
716541f000-7165420000 r--p 00000000 00:00 0 [anon:cfi shadow]
7165420000-71654db000 ---p 00000000 00:00 0 [anon:cfi shadow]
71654db000-71654dc000 r--p 00000000 00:00 0 [anon:cfi shadow]
71654dc000-71654dd000 r--p 00000000 00:00 0 [anon:cfi shadow]
71654dd000-71654f0000 ---p 00000000 00:00 0 [anon:cfi shadow]
71654f0000-71654f1000 r--p 00000000 00:00 0 [anon:cfi shadow]
71654f1000-71e5151000 ---p 00000000 00:00 0 [anon:cfi shadow]
This change degrades CFI diagnostics for wild jumps and casts (i.e. when
the target of a CFI check is outside of any known library bounds). This
is acceptable, because CFI does not have much to tell about those cases
anyway. Such bugs will show up as SEGV_ACCERR crashes inside
__cfi_slowpath in libdl.so from now on.
Bug: 158113540
Test: bionic-unit-tests/cfi_test.*
Test: adb shell cat /proc/$PID/maps | grep cfi
Change-Id: I57cbd0d3f87eb1610ad99b48d98ffd497ba214b4
Merged-In: I57cbd0d3f87eb1610ad99b48d98ffd497ba214b4
In particular, add the strerror() output if mprotect() fails.
Fix the CHECK macro so that you can make assertions involving operator%
without that being confused for a printf format specifier.
Bug: https://issuetracker.google.com/158645318
Test: treehugger
Change-Id: I6817f8ca5f094c52dc2c9067bfac90385a8743f5
.whitelisted is a list of sonames seperated by ":" just like
.shared_libs and .paths properties. It makes sense to make it appendable
using += as well ass .shared_libs and .paths.
Bug: n/a
Test: atest linker-unit-tests
Change-Id: If61cc553c8080e8a58de8a3a6051c1853f7bfe5f
Change the location set in the linker
Bug: 130219528
Bug: 138994281
Test: atest CtsBionicTestCases
Test: atest CtsJniTestCases
Change-Id: I215a8e023ccc4d5ffdd7df884c809f8d12050c8f
The SYNC tagging level enables stack trace collection for allocations and
deallocations, which allows allocation and deallocation stack traces to
appear in tombstones when encountering a tag check fault in synchronous tag
checking mode.
Bug: 135772972
Change-Id: Ibda9f51b29d2c8e2c993fc74425dea7bfa23ab1e
Before this Soong added hardcoded system include paths to
bionic/libc/{include,kernel}, which won't work when Bionic libs are
packaged up as prebuilts in an SDK module snapshot.
Test: Build and boot
Test: Check in out/verbose.log.gz that a C file doesn't get any bionic
include path for linux_glibc.
Bug: 153590472
Change-Id: I13c8eb3dd7150d6e0fee001b290b53fcebebcfea
CfiFail calls find_containing_library, which searches the linker's
internal soinfo list, which could be modified by another thread.
Bug: http://b/150372650
Test: bionic-unit-tests
Change-Id: I59024a0a47913caa75702f15ec058b0a360727b5
android_get_exported_namespace searches g_exported_namespaces, which
isn't modified after process initialization, but it does the search
using a new std::string object, and the linker's malloc/free functions
aren't thread-safe. (They're protected by the same lock (g_dl_mutex) as
the rest of the linker's state.)
Bug: http://b/150372650
Test: bionic-unit-tests
Change-Id: Iafd12e5ab36ae61f0642aad59939f528d31bda16
For the bootstrap linker, insert /system/${LIB}/bootstrap in front of
/system/${LIB} in any namespace search path.
Bug: http://b/152572170
Test: bionic unit tests
Change-Id: Ia359d9f2063f4b6fff3f79b51b500ba968a18247
If ElfReader::Read fails, then it is hazardous to leave the invalid
ElfReader in the soinfo*->ElfReader table, because a future soinfo
object could happen to have the same address, then reuse the invalid
ElfReader. I'm not sure whether this can break anything, because the
linker would call ElfReader::Read on the invalid object and overwrite
its previous value.
Test: bionic unit tests
Bug: none
Change-Id: Ibabbf559443441b9caeacc34ca165feaafe5e3a7
The doc_link argument is really a URL fragment within the
android-changes-for-ndk-developers.md document, not a filename at the
root of the bionic repository.
Test: manual
Bug: none
Change-Id: I1b542e47aca132ce43ba1d50d83db1bf3c7b10c6
The search_linked_namespaces parameter to find_library_internal is
always true.
Bug: none
Test: bionic tests
Change-Id: I4b6f48afefca4f52b34ca2c9e0f4335fa895ff34
Add a few _Nonnull / _Nullable annotations. Clang may use them to issue
warnings but violating the annotation isn't undefined behavior.
Bug: none
Test: bionic tests
Change-Id: I82e442f06a2c59c69bc0008f0f686785695cdd02
This reverts commit 8dba7fefb0.
Reason for revert: This workaround is not necessary with ag/10700799
Merged-In: I2bf469bfe00f3a70e67085abfb3822db6908d522
Change-Id: If351aedfce23d60582f0c5ff965f94356d1900d9
Bug: 150860940
Update message that generated linker configuration is missing to from
into to warning again. Also do not raise this message from host
environment which is expected.
Bug: 146386369
Test: m -j passed
Change-Id: Ia5c2969d77fbc70e0406fbb449920080989a1ea8
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
Exports GWP-ASan allocator information callbacks to libdebuggerd so that
tombstoned can get information from the GWP-ASan allocator in the case
of a crash.
Bug: 135634846
Test: atest bionic-unit-tests
Change-Id: Ie16426af55602fb2a76c4e69217773354c365843
sys.linker.use_generated_config property was introduced at the beginning
of linkerconfig development to skip this generated configuration if it
does not work properly during dev. However, linkerconfig development is
now completed and is working properly from most of devices, so this
property is no longer in use. Therefore deprecating this property as
this would not be used.
Bug: 149335054
Test: m -j passed
Test: No linking error from Cuttlefish and Crosshatch
Change-Id: I0a1b3f36b69872862196b1613718a75d482e0a92
XOM is no longer supported by the build system, so remove these
properties.
Bug: 123034666
Bug: 147300048
Test: Build succeeds.
Change-Id: I77efc98241f45b1a78b1cca5560f64eef5ef22f4
When a library is present in a namespace via the secondary_namespaces
list (i.e. the executable, LD_PRELOAD, DF_1_GLOBAL, or
android_create_namespace inheritance), then we want to search that
library's symbols, but not the symbols of its dependencies. Otherwise,
we want to search the dependencies to handle cross-NS dependency.
Bug: http://b/148569846
Test: bionic unit tests
Change-Id: If798d69de28ed5c0f1a155e4ff85c7e08934e531
LinkerConfig will start to generate linker configuration for APEX
binaries. Linker should check if this generated file exists first, and
use it if exists and otherwise use ld.config.txt under APEX etc.
Bug: 147987608
Test: m -j passed
Test: Tested with adbd and SWCodec from Cuttlefish and Crosshatch
Change-Id: I5a0c28ee1a427adface3e67c8af062e1b2ef6197
Until now we've only supported RELR with our own OS-private-use
constants. Add support for the official numbers (while maintaining
support for the historical numbers).
Add tests to ensure we continue to support both indefinitely.
We can't yet flip the build system over to using the official constants
because the old GNU binutils objcopy we still use in most cases (for the
mini-debug section) only supports the historical constants.
Bug: http://b/147452927
Test: treehugger
Change-Id: If214fce7fade4316115947e90b78ab40864b61f2
A static analyzer is complaining that num_valid_bits could be 64, and if
it were 64, then two later accesses would be out-of-bounds. is_nul_u64
can't be zero, though, because we only exit the loop when part of is_nul
is non-zero.
Bug: none
Test: manual
Change-Id: I75c3f70b600aa5478cb32fdf4ca0ae1173b69524
Previously, the linker was ignoring the symbol of the R_GENERIC_NONE
relocation, so continue ignoring it. This is a little unfortunate because
it requires adding an extra condition on the fast path for relocation
handling.
I tried benchmarking this change, and I can't tell whether it has no
effect or is a regression of up to 1%. It might be possible to refactor
this code (e.g. do the lookup anyway, but avoid reporting an error), or by
changing the linker behavior, but this simple change gets the linker
working again.
Bug: http://b/147719203
Test: verify that the broken app works again
Change-Id: I7589b65705fec522d5fbadc05136dd5489833aea
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
These are no longer necessary now that LLVM no longer emits references to
this symbol on Android.
Bug: 144430859
Change-Id: I6c43338f755ce5a79e2df36bd3f2006a748fab27
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
Validate the list of defined versions explicitly, during library
prelinking, rather than implicitly as part of constructing the
VersionTracker in soinfo::link_image.
Doing the validation upfront allows removing the symbol lookup failure
code paths, which only happen on a library with invalid version
information.
Helps on the walleye 64-bit linker relocation benchmark (146.2ms ->
131.6ms)
Bug: none
Test: bionic unit tests
Change-Id: Id17508aba3af2863909f0526897c4277419322b7
Previously, during a find_libraries call that loaded a library, a
library was prelinked once for each DT_NEEDED reference to the library.
This CL has a negligible effect on the linker relocation benchmark
(146.9ms -> 146.2ms).
Bug: none
Test: bionic unit tests
Change-Id: I385f312b8acf8d35aa0af9722131fe367b5edd9b
The soinfo instances of linker and vdso have been added to g_default_namespace
before init_default_namespace() is called. So init_default_namespace() don't
have to add them a second time.
Test: manual
Change-Id: I29b3da782b1e9445509f45a7698561fc3e19e9a1
Historically we've made a few mistakes where they haven't matched the
right number. And most non-Googlers are much more familiar with the
numbers, so it seems to make sense to rely more on them. Especially in
header files, which we actually expect real people to have to read from
time to time.
Test: treehugger
Change-Id: I0d4a97454ee108de1d32f21df285315c5488d886
DL_WARN message when failed to find generated linker config makes some
of the ART tests fail. Lowering log level as ART test does not have
linkerconfig generated for the test.
Bug: 146386369
Test: Cuttlefish boot succeeded without any error
Test: run_build_test_target.py art-linux-bionic-x64-zipapex passed
Change-Id: I4f876c3ac5c30d32d51346d4cd16b5205da8f1bf
New linker configuration from /linkerconfig is not suitbale for emulated
architectures. But as of now, native_bridge linkers pick it up as well
and thus fail to find the libraries for emulated architectures.
This is a (temporary) fix so native_bridge linker still picks up
configuration from old location.
Bug: 138920271
Test: native_bridge linker works
Change-Id: I0abbd3e95f9e6830385b0f19db0688e6183030b9
Current linker configuration is only enabled from fully treblelized
devices. This change will allow linker to first check generated linker
configuration even for non-treblelized devices and recovery.
Bug: 139638519
Test: Tested from cuttlefish
Change-Id: I655b1ab807cd8db5696d07fd2bdd00ce0558901d
Due to some special environment, linker config should not be located
under /dev partition. It would be better to relocate linker config under
new root dir /linkerconfig.
Bug: 144966380
Test: m -j && tested from cuttlefish
Change-Id: Icda1d2ef34b42159c6ebce58b03211cc13f08121
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
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
Make fdsan fatal by default on native processes, and Java processes that
target R or later.
Bug: http://b/137788030
Test: manual
Change-Id: I5900efc606fc0d47b69223574ad7dca89afe4eda
Linker config now generates ld.config.txt under /dev/linkerconfig from
init. To use this, this change updates linker to pick up
/dev/linkerconfig/ld.config.txt if system property
(sys.linker.use_generated_config) is true.
Bug: 138920271
Test: m -j && tested from cuttlefish
Change-Id: I0f527741ace2d512b45fd72c301aa4cfcfe17a71
These hooks notify the HWASan runtime library whenever a library is loaded
or unloaded so that it can update its shadow memory.
Bug: 138159093
Test: walleye_hwasan-userdebug boots with+without https://reviews.llvm.org/D65770
Change-Id: I6caf2a6540ed2c0d94db444e806a3c7ba504cabb
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 AArch64 ELF specification originally specified these relocations:
R_AARCH64_TLS_DTPREL64 1028
R_AARCH64_TLS_DTPMOD64 1029
However, the GNU toolchain implemented them as:
R_AARCH64_TLS_DTPMOD64 1028
R_AARCH64_TLS_DTPREL64 1029
The AArch64 ELF specification has been updated to replace the relocations
with R_AARCH64_TLS_IMPDEF1 and with R_AARCH64_TLS_IMPDEF2, where each
implementation can choose which interpretation it implements, but with a
suggestion to follow the GNU behavior.
Also: remove the 64 suffixes from the TLS relocations. The newest version
of the AArch64 ELF specification (version f) also omits the suffixes, as
do the glibc headers.
Bug: http://b/123385182
Bug: https://bugs.llvm.org/show_bug.cgi?id=40507
Test: build device, it boots
Change-Id: Ie98b7624752982973f0ac969d646454a86784cab
When relocating a DSO, it is not unusual to have consecutive
relocations using the same symbol. In this case, it is wasteful to
perform the same symbol lookup. This change implements an 1-entry
symbol cache so that symbol lookup results are reused in such scenario.
Test: On cuttlefish, enable STATS in linker_debug.h. Boot and see RELO
STATS in logcat showing cache hits. Hit rate seen is mostly
within 15% to 45%.
Change-Id: I84783d3b9a6ac9e39ed7fb45e58f6b3c012478d0
The demangler is moving out of libc++abi to save on bloat.
Test: make checkbuild
Bug: http://b/138245375
Change-Id: I7402894bb326f524388c9efdf86509dad50f2018
Previously, the linker configuration of an APEX would only be used for
executables located exactly in its `bin` directory. This change
relaxes this condition to also include executables located in any
directory under the APEX's `bin` directory.
This change is needed to support APEX binaries located in directories
under the APEX's `bin` directory that need to use the APEX's linker
configuration (e.g. ART gtests located in
`bin/art/{arm,arm64,x86,x86-64}` in the Testing Runtime APEX).
Test: Run ART gtests on device using the Testing Runtime APEX
Bug: 129534335
Change-Id: I0eac317eba856211a344fa00e66640aae10816ea
Before:
$ ldd toybox
toybox: not an ELF file
After
$ ldd toybox
toybox: cannot open
I've also sent a toybox patch upstream to make that:
$ ldd toybox
toybox: cannot open: No such file or directory
Test: manual
Change-Id: If961cdf6f2f2f8d4f6cdfcade9061e49a09d1f01
Ordinary executables have a PT_INTERP path of /system/bin/linker[64], but:
- executables using bootstrap Bionic use /system/bin/bootstrap/linker[64]
- ASAN executables use /system/bin/linker_asan[64]
gdb appears to use the PT_INTERP path for debugging the dynamic linker
before the linker has initialized the r_debug module list. If the linker's
l_name differs from PT_INTERP, then gdb assumes that the linker has been
unloaded and searches for a new solib using the linker's l_name path.
gdb may print a warning like:
warning: Temporarily disabling breakpoints for unloaded shared library "$OUT/symbols/system/bin/linker64"
If I'm currently debugging the linker when this happens, gdb apparently
doesn't load debug symbols for the linker. This can be worked around with
gdb's "sharedlibrary" command, but it's better to avoid it.
Previously, when PT_INTERP was the bootstrap linker, but l_name was
"/system/bin/linker[64]", gdb would find the default non-bootstrap linker
binary and (presumably) get confused about symbol addresses.
(Also, remove the "static std::string exe_path" variable because the
soinfo::realpath_ field is a std::string that already lasts until exit. We
already use it for link_map_head.l_name in notify_gdb_of_load.)
Bug: http://b/134183407
Test: manual
Change-Id: I9a95425a3a5e9fd01e9dd272273c6ed3667dbb9a
Rearrange the st_dev and st_ino checks to reduce the number of
comparison needed.
Test: Ran cameraserver on a Go device. Measured time spent in the linker
and saw ~1% speed-up.
Change-Id: I8e977ff37925eae3ba8348e7c4a01ce8af3b9b6d
A linker namespace lives longer than its caller. It is never deleted
once created in a process. Currently, the pointer to the name is simply
copied which results dangling reference when the name is actually from
temporary objects like std::object. Fixing the issue by strdup'ing the
name upon namespace creation.
Bug: 130388701
Test: atest CtsJniTestCases; the log does not show broken error messages
like
unexpected dlerror: dlopen failed: library "/system/lib64/android.frameworks.cameraservice.common@2.0.so" needed or dlopened by "/data/app/android.jni.cts-HP6GyGXYy5honHQAffUXgw==/lib/arm64/libjnitest.so" is not accessible for the namespace " mT?"
Change-Id: I25d9d76f8520f490755c189ded5659e6c9741f79
When parsing ld.config.txt, paths in *.search.paths properties are
resolved using resolved_paths(). This is causing a number of newfstatat
system calls during a process start-up and is contributing about 3.6%
of the entire linker initialization time.
Optimize the overhead by not resolving already resolved paths; resolved
paths are cached.
Bug: 132348336
Test: strace -C -e newfstatat ls shows the number of the syscalls is
reduced from 131 to 99
Test: simpleperf record --call-graph fp -f 10000000 -o /data/perf.data ls
simpleperf report -g -i /data/perf.data
shows percentage of get_paths() from 2.9% to 2.5%
Change-Id: I79823255a89f6e2a63b80c74e6768850276ab536
A proposed set of changes:
https://android-review.googlesource.com/q/topic:"no-dup-hwasans"
will cause the HWASAN runtime to be moved from /system/lib64 to
/system/lib64/bootstrap. This causes a problem in the case where libc is built
with HWASAN but init is not built with HWASAN. In this case, libc.so will have
a DT_NEEDED dependency on the HWASAN runtime but init will not. Currently,
init and other bootstrap executables arrange to load bootstrap libraries by
setting rpath, but rpath only has an effect on libraries directly depended
on by the main executable, not libraries indirectly depended on by it. This
means that the loading of the HWASAN runtime will fail.
Instead of relying on rpath to find the bootstrap libraries, modify the
bootstrap linker so that it searches the bootstrap library directory after
searching the rpath.
Change-Id: I297be32e04ecd316ee12b8e694588e1249e2bb89
Creating two huge buffers with std::vector, as it is now, is very
expensive, because it ends up being satisfied with mmap()/munmap().
Instead, we statically allocate a large string buffer while resizing
the other one to be a smaller and more appropriate size so that it can
be placed on the stack.
Note that this does mean that we increase linker data segment by 4KB
and that increases the overall system memory usage by about 400KB.
However, since that additional page is mostly zeroed with only some
ASCII text, it should be fairly easy to compress when it's swapped out
to ZRAM.
Test: Run with strace and observe no mmap/munmap around readlinkat().
Test: Measure average linker time of starting cameraserver on a Go
device and see ~3% speed-up.
Bug: 132783386
Change-Id: I600cc7a92be316ef67440a9a28c05d18de229f6c
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 libstdc++ directory has no copyright headers, so it was a no-op
anyway.
The interesting part will be switching libc and libm over to genrules...
Test: N/A
Change-Id: Iec92562af40c451fdcb4a7468984878ec5dba2ce
ANDROID_DLEXT_WRITE_RELRO was inadvertently writing out the RELRO
section of all libraries loaded during a given dlopen() call instead of
only the main library; since the other libraries are loaded at
unpredictable addresses this additional data is rarely useful.
Fix this to only happen when the
ANDROID_DLEXT_RESERVED_ADDRESS_RECURSIVE flag is being used.
Bug: 128623590
Test: DlExtRelroSharingTest.CheckRelroSizes
Change-Id: I05e8651d06ce2de77b8c85fe2b6238f9c09691ad
ANDROID_DLEXT_WRITE_RELRO was causing the GNU RELRO sections of
libraries to become corrupted if more than one library was being loaded
at once (i.e. if the root library has DT_NEEDED entries for libraries
that weren't already loaded). The file offset was not being correctly
propagated between calls, so after writing out the (correct) RELRO data
to the file, it was mapping the data at file offset 0 for all libraries,
which corrupted the data for all but one of the libraries.
Fix this by passing file_offset as a pointer the same way that
phdr_table_map_gnu_relro does.
Bug: 128623590
Test: tbd
Change-Id: I196cd336bd5a67454e89fd85487356b1c7856871
Also update an rvalue reference to lvalue reference where it's
unnecessary to make it clearer.
Test: Build and boot cuttlefish.
Change-Id: Ib799666ab075523e6446f34c7da2b1eb311f98ab
In order to enable no-vendor-variant VNDK, we need a way to restrict a
namespace to only a list of whitelisted libraries. We add a new
"whitelisted" property for this. If the property is not set, all
libraries in the search paths are available in a namespace. If the
property is set, only the libraries named are available.
Bug: 119423884
Test: Boot with no-vendor-variant VNDK enabled using the new property.
Change-Id: Id808c1733c8e2c2c3462b04c72461f9698403571
- Show which executable is being linked, which linker config file is
being read, and which section in it is being used with, enabled on
$LD_DEBUG>=1.
- Show more info to follow the dlopen() process, enabled with "dlopen"
in the debug.ld.xxx property.
Test: Flash, boot, and look at logcat after "adb shell setprop debug.ld.all dlopen"
Bug: 120430775
Change-Id: I5441c8ced26ec0e2f04620c3d2a1ae860b792154
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
Make the num_free_blocks calculation clearer. There are
sizeof(page->bytes) bytes available for blocks, which is equal to
(kAllocateSize - 16). The previous calculation overestimates the amount
of space by 8 or 12 bytes, but that doesn't change the result because
both kAllocateSize and block_size_ are multiples of 16.
Bug: none
Test: boot device, bionic unit tests
Change-Id: Ia880cd5abc2a7bb4e9e6a8c0441d985f4df8fdc4
The tlsdesc_resolver_dynamic function is only defined on arm64, but the
code was taking its address on all targets. (Apparently the optimizer was
removing the entire deferred_tlsdesc_relocs loop?)
Bug: none
Test: bionic unit tests
Test: add -O0 to cc_defaults in linker/Android.bp, device boots
Change-Id: I899c78018cbe82aeaca7856c9f7b04300c1d3196
It's possible and sometimes beneficial for a library to have disjoint mappings
and for other libraries to be mapped into the gap between the mappings using
ANDROID_DLEXT_RESERVED_ADDRESS. See for example the proposal for partitioning
in lld [1].
Because the find_containing_library and do_dl_unwind_find_exidx functions use
a simple bounds check to figure out whether a pointer belongs to a library
they will, given a pointer into a library mapped into the gap of a library
with disjoint mappings, return a pointer to the soinfo for the outer library
instead of the inner one, because the outer library will appear before the
inner one in the solist.
From a user perspective this means that we won't be able to unwind the inner
library's frames on 32-bit ARM with libgcc, dladdr() will return information
for the outer library given a pointer to the inner one and dlopen() et al will
use the linker namespace of the outer library when called from the inner one
(although they will usually be the same).
To make this work correctly, make it so that once find_containing_library
sees a match for the bounds check, it examines the library's PT_LOADs to
make sure that there is a mapping for the given address. This is similar
to how libgcc and libunwind_llvm already handle finding the PT_GNU_EH_FRAME
on non-ARM32 platforms [2,3]. do_dl_unwind_find_exidx is reimplemented in
terms of find_containing_library.
[1] http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html
[2] e739ac0e25/libunwind/src/AddressSpace.hpp (L523)
[3] https://android.googlesource.com/toolchain/gcc/+/master/gcc-4.9/libgcc/unwind-dw2-fde-dip.c#294
Test: /data/nativetest{,64}/bionic-unit-tests/bionic-unit-tests on walleye-userdebug
Change-Id: I368fe6ad3c470b3dff80f7d9b04253566d63a7d2
Introduce a new flag ANDROID_DLEXT_RESERVED_ADDRESS_RECURSIVE which
instructs the linker to use the reserved address space to load all of
the newly-loaded libraries required by a dlopen() call instead of only
the main library. They will be loaded consecutively into that region if
they fit. The RELRO sections of all the loaded libraries will also be
considered for reading/writing shared RELRO data.
This will allow the WebView implementation to potentially consist of
more than one .so file while still benefiting from the RELRO sharing
optimisation, which would otherwise only apply to the "root" .so file.
Test: bionic-unit-tests (existing and newly added)
Bug: 110790153
Change-Id: I61da775c29fd5017d9a1e2b6b3757c3d20a355b3
