This library was previously being statically linked into both libraries as a
consequence of the relocation to __aeabi_unwind_cpp_prX present in most object
files. However, after LLVM commit 1549b469, we no longer emit these relocations
on Android, so we need to link the library explicitly with --whole-archive. The
intent is to eventually stop linking libgcc into these libraries altogether,
but for now, we need to keep linking them in order to avoid breaking the build.
Change-Id: I275109527b7cbd6c4247b3fe348975d720626273
aosp/144287300 set it to a global cppflag.
The compiler upgrade can now check for this warning in C code.
This patch should be reverted once the BSD sources with instances of
-Wimplicit-fallthrough have been fixed.
Remove it from cflags, so that it's not re-enabled for C code until
fixed.
Bug: 139945549
Bug: 144287300
Test: mm
Change-Id: Ieca0d5b41634636477392e5209a41807f9b44bd4
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
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)
This will activate code in bionic that uses the experimental MTE
userspace interface.
Bug: 135772972
Change-Id: I9ac641b9528de5376cdb920bee0e900a1b1fa9c2
This flag prevents the compiler from inserting calls to libc functions in
the ifunc resolver code, which will definitely cause problems if the libc
function is itself an ifunc, but other calls that use the PLT may also be
affected, since libc may not have been fully resolved yet. As it turns out,
newer versions of clang will insert calls to memcmp in the body of the
init_cpu_variant() function in arch-arm/dynamic_function_dispatch.cpp.
Change-Id: I91f18d450835adc4b74565e9f48d5834f594a0c4
As it turns out, our "generic" arm64 implementations of certain string.h
functions are not actually generic, since they will eagerly read memory
possibly outside of the bounds of an MTE granule, which may lead to a segfault
on MTE-enabled hardware. Therefore, move the implementations into a "default"
directory and use ifuncs to select between them and a new set of "mte"
implementations, conditional on whether the hardware and kernel support MTE.
The MTE implementations are currently naive implementations written in C
but will later be replaced with a set of optimized assembly implementations.
Bug: 135772972
Change-Id: Ife37c4e0e6fd60ff20a34594cc09c541af4d1dd7
Upstream keeps rearranging the deckchairs for these, so let's just
switch to the [roughly] one-liners rather than track that...
Test: treehugger
Change-Id: If655cf7a7f316657de44d41fadd43a8c55ee6f23
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
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
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
Refactor some of the definitions to separate out all of the native
allocator pieces into one place that can be changed easily. This
should fix a few static libraries that appear to have accidentally
included jemalloc wrapper functions. For example, I verified that
libc_nomalloc.a no longer has references to any je_XXX functions.
Modify the bionic_libc_platform_headers to not include any libraries.
If this isn't updated, soong thinks there are cycles when used by
libscudo.
To enable scudo, change the libc_native_allocator_defaults defaults
from libc_jemalloc5_defaults to libc_scudo_defaults and comment out
the defaults: ["libc_scudo_wrapper_defaults"], line for the shared
library libc_scudo.
To do a final switch to scudo, it will be necessary to clean up
some code in other parts of the tree, but this allows a single cl
to enable or disable.
Bug: 137795072
Test: Builds with jemalloc or scudo with a small change.
Test: Ran bionic unit tests.
Change-Id: I07bb5432a0d2b2f405f92412e8d04fb9c9e51b31
Merged-In: I07bb5432a0d2b2f405f92412e8d04fb9c9e51b31
(cherry picked from commit ccff1b19ef)
The tables in the BSD tolower/toupper are slower for ASCII than just
doing the bit twiddling.
We can't actually remove the tables on LP32, so move them into the
"cruft" we keep around for backwards compatibility (but remove them for
LP64 where they were never exposed).
I noticed that the new bit-twiddling tolower(3) was performing better
on arm64 than toupper(3). The 0xdf constant was requiring an extra MOV,
and there isn't a BIC that takes an immediate value. Since we've already
done the comparison to check that we're in the right range (where the
bit is always set), though, we can EOR 0x20 to get the same result as
the missing BIC 0x20 in just one instruction.
I've applied that same optimization to towupper(3) too.
Before:
BM_ctype_tolower_n 3.30 ns 3.30 ns 212353035
BM_ctype_tolower_y 3.31 ns 3.30 ns 211234204
BM_ctype_toupper_n 3.30 ns 3.29 ns 214161246
BM_ctype_toupper_y 3.29 ns 3.28 ns 207643473
BM_wctype_towupper_ascii_n 3.53 ns 3.53 ns 195944444
BM_wctype_towupper_ascii_y 3.48 ns 3.48 ns 199233248
After:
BM_ctype_tolower_n 2.93 ns 2.92 ns 242373703
BM_ctype_tolower_y 2.88 ns 2.87 ns 245365309
BM_ctype_toupper_n 2.93 ns 2.93 ns 243049353
BM_ctype_toupper_y 2.89 ns 2.89 ns 245072521
BM_wctype_towupper_ascii_n 3.34 ns 3.33 ns 212951912
BM_wctype_towupper_ascii_y 3.29 ns 3.29 ns 214651254
(Why do both the "y" and "n" variants speed up with the EOR
change? Because the compiler transforms the code so that we
unconditionally do the bit twiddling and then use CSEL to decide whether
or not to actually use the result.)
We also save 1028 bytes of data in the LP64 libc.so.
Test: ran the bionic benchmarks and tests
Change-Id: I7829339f8cb89a58efe539c2a01c51807413aa2d
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)
The accompanying soong change causes sanitize attributes to be allowed on
cc_object targets and propagates sanitize attributes into dependencies. This
is problematic for the crt objects in sanitizer builds because everything
depends on them including the sanitizer runtime, so a circular dependency
would otherwise be created. Furthermore, some of the code in these objects
runs before sanitizer initialization so it is unlikely that sanitizing them
would work anyway. Therefore, disable sanitization on these objects.
Change-Id: I25380dfc8eed5db34b034ba127a9d6b5674032fa
Instead of having platform directories directly include the
private header, create a platform header directory and export it.
Bug: 130763340
Test: Builds.
Change-Id: Ie0f092b3fe077a3de8b90266c0b28bfbc20d0dfa
Merged-In: Ie0f092b3fe077a3de8b90266c0b28bfbc20d0dfa
(cherry picked from commit 8f582ef2f8)
Split statfs and statvfs. The former has been available forever, and the
latter is implemented in terms of the former. The implementation has
been moved into headers so that it can be used at low API levels.
There's no reason for any Android or Linux code to use statvfs rather
than statfs, but code that needs to build on Darwin too will want to use
statvfs because Darwin's statfs is very spartan.
Bug: https://github.com/android-ndk/ndk/issues/609
Test: treehugger
Change-Id: Icf3d5723a260099fddb2d9f902e3047b0f041647
Instead of maintaining a symbol ordering file, using the new
sort_bss_symbols_by_size property allows for symbol sorting at build
time.
Bug: 135754984
Test: Build and check the resulting libc.so has its bss symbols sorted.
Change-Id: I4a1cd6774dfe61b73f454bdf95b535db1f9fb1ac
This avoids art having a direct reference to bionic directories which
would prevent the bionic module from being unbundled from the runtime
module.
Bug: 134379140
Test: m droid
Change-Id: I9545767b76341fd01166b675bdd156f620d4f262
We're not going to change this code, ARM's not going to break it.
Silence the warnings.
Bug: http://b/114120867
Test: treehugger
Change-Id: Ie25ef44706c952efc5d54012391bee19af095818
Cleanup of references to 'coverage' in build files. Part of a larger
cleanup to make fuzzing work again in the Android build tree.
Also fixed a test issue with emulated TLS with the new changes, and
removed libc.so fuzzer support until a linked bug is fixed
(b/132640749).
Bug: 121042685
Test: With all patches in the bug merged: mmma bionic
Change-Id: I592352fe9210ff811a2660a88cbbfe48d70a1e57
Merged-In: I592352fe9210ff811a2660a88cbbfe48d70a1e57
The arm exidx unwind information can be sparse and clang is producing
functions that cannot be properly represented. The .debug_frame includes
extra unwind information that covers the cases that are not complete, so
do not remove it. For example, the __strchr_chk function has a push
in the middle of the function, so any crash before that instruction will
not unwind properly.
This does increase the size of libc.so, but only by about 80,000 bytes.
Bug: 132992102
Test: Verified the .debug_frame exists in libc.so only for arm32.
Test: Used the unwind_reg_info to verify that __str_chk gets proper
Test: unwind info. Also use unwind_reg_info on some assembler functions
Test: to make sure that there is no overlapping information.
Change-Id: If9a6de15b3adf08a93c4563da8c89846e4dd059b
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
Move /system dependency on tz_version to bionic from core-libart.
The file is not used by code but is useful on device to identify
the format / version / origin of the tzdata file. The
tz_version file identifies the Android release (e.g. 3.1 == Q), which
implies the version of zic used to generate tzdata, and any Android
revision of the tzdata (e.g. 2019a v2) that may have taken place. The
file was previously used by by the tzdatacheck binary but it has since
switched to using the copy in the runtime module.
The bionic README.md is also updated here to reflect latest locations of
scripts.
Bug: 131239046
Test: make installclean / make droid / inspect /system
Change-Id: Ib142f98aa30c8c9d5eda33df55d4191478570ced
FreeBSD, glibc, and musl have all implemented C11 threads at this
point. POSIX is looking at how to align with it. Probably time to jump
on the bandwagon ourselves...
Implemented in the same style as <termios.h> so we can provide this
functionality even on older API levels. This does mean that this is
strictly more expensive than calling pthread functions directly.
Although this isn't in POSIX yet, assume that it's going to be basically
the same as C11 and add the header test anyway. We should revisit this
when POSIX actually adds <threads.h>.
Test: new tests
Change-Id: I8602d67ce71ca7f8ed1529daa0a8ea1feb083dd6
These symbols were previously provided by Android's out-dated libgcc,
but they're removed/deprecated in upstream libgcc, and also won't be
available in libclang_rt.builtins. We need to provide these methods in
libc itself for compatiblity.
Test: build with these symbols stripped in libgcc
Bug: 29275768
Change-Id: I04a05258c6c06b5a22ead41e148b02792ffbc941
This reverts commit e4788d4c7e,
which undid this change during the Q betas.
Bug: http://b/120989619
Change-Id: Iea589fd0e56426971adf9f7c19c2aedf0d7a7a60
...all the better to switch to a genrule rather than checking in
generated source.
This also removes all the code in the script to deal with git,
rather than fix it. We won't need that where we're going.
Test: boots
Change-Id: I468ce019d4232a7ef27e5cb5cfd89f4c2fe4ecbd
/system/lib/libc.so is a symlink to libc.so in the runtime APEX.
libc_malloc_* libraries are bundled with libc.so because they share
implementation details.
However, since libc.so is loaded in the default namespace where the
runtime APEX path (/apex/com.android.runtime/lib) is not accessible,
libc.so has been using libc_malloc_* from /system/lib. This is
wrong because libc.so (from the runtime APEX) and libc_malloc_* (from
the platform) may not be in-sync.
libc.so now uses android_dlopen_ext to load libc_malloc_* libraries
correctly from the "runtime" linker namespace.
Bug: 122566199
Test: bionic-unit-tests
Merged-In: I46980fbe89e93ea79a7760c9b8eb007af0ada8d8
Change-Id: I46980fbe89e93ea79a7760c9b8eb007af0ada8d8
(cherry picked from commit 4e46ac69c2)
The media processes already use scudo as their allocator. However, it
doesn't really correctly replace the normal allocation functions, so create
a set of wrappers that allow us to use scudo closer to how jemalloc is used.
This is only a temporary change, and should be removed for the next
release of Android. In that version, we will be using standalone
scudo which won't require this wrapper code.
Bug: 123689570
Test: Ran new bionic unit tests. There are failures, but only with
Test: extensions that scudo does not support.
Change-Id: I0516c23d654a9b6c69b157c5501245d2e0b3d264
With __cpu_model visibility issue fixed in libcrt, we can move x86 and
x86_64 libc to use libcrt as well.
Test: emulator boots
Bug: 122993569
Change-Id: If71c324180010a57e3e9598d758a4d6ab1a3c369
Introduce an M_SET_ALLOCATION_LIMIT enumerator for android_mallopt(),
which can be used to set an upper bound on the total size of all
allocations made using the memory allocation APIs.
This is useful for programs such as audioextractor and mediaserver
which need to set such a limit as a security mitigation. Currently
these programs are using setrlimit(RLIMIT_AS) which isn't exactly
what these programs want to control. RLIMIT_AS is also problematic
under sanitizers which allocate large amounts of address space as
shadow memory, and is especially problematic under shadow call stack,
which requires 16MB of address space per thread.
Add new unit tests for bionic.
Add new unit tests for malloc debug that verify that when the limit
is enabled, malloc debug still functions for nearly every allocation
function.
Bug: 118642754
Test: Ran bionic-unit-tests/bionic-unit-tests-static.
Test: Ran malloc debug tests and perfetto integration tests.
Change-Id: I735403c4d2c87f00fb2cdef81d00af0af446b2bb