* changes:
crtbegin_static is built with min_sdk_version: "current"
Guard __libc_current_sigrtmin/max with __builtin_available
__INTRODUCED_IN macros add the availability attribute
Native bridge modules will never compile against stubs, remove
native_bridge_supported: true.
Test: m checkbuild
Change-Id: I0eb93fe1a2c3f6ca34ce4dab17edda8807132ce8
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
These are available from mallopt() now, and all callers have been
switched over.
Bug: http://b/135772972
Test: treehugger
Change-Id: I90c7a7573b261c27001a2dfd4589b23861ad613b
crtbegin_static is used by static exectuables which are guaranteed to be
with the latest library regardless of their target API level.
This change is in fact not a regression as crtbegin_static has been
built with __ANDROID_API__=10000 before
I645e6bb1234c27ae0a69b7b87a59206cfd350744 when __ANDROID_API__ tracked
sdk_version, not min_sdk_version. sdk_version was not set for crtbegin_*
objects and therefore the default "current" was (incorrectly) used.
With this change, we are recovering the original behavior for the static
variant, while the building of the dynamic variant becomes more correct
- it's now with __ANDROID_API__=16.
Without this change, several static executables fail to build as 1)
crtbegin_static for them is built with __ANDROID_API__=16 and 2)
libc_init_common.cpp uses pthread_atfork which is available only after
API level 23. We hit undefined symbol error when linking.
Bug: 134795810
Test: m
Change-Id: I1430e57302951df33530ea0ae91b0d7a0609bf3d
The two APIs were added for the API level 21 and beyond. Currently, its
existence is tested using the null check which is done regardless of the
min sdk version of the compilation unit. (which in turn required us to
mark the API symbol weak regardless of the min sdk version.)
Now, we have a better way of testing the API availability;
__builtin_available. The null check is replaced with the call to the
compiler-provided macro which determines if the code is running in a
version of OS where the API is known to exist.
Bug: 150860940
Bug: 134795810
Test: m
Change-Id: Ib96c78f8d3cc71d7e755d1eab86051517bbbcc44
__INTRODUCED_IN (and its variants) macro is used to mark the
availability of an API symbol. The macros were used by the versioner
tool for the NDK clients. When the Bionic headers are processed by the
tool, APIs with the macros are guarded with __ANDROID_API__. e.g.,
void foo() __INTRDUCED_IN(30);
is processed into
\#if __ANDROID_API__ >= 30
void foo();
\#endif
by the versioner.
The macros however didn't play a role for other cases, e.g. OS
components.
This is too strict for NDK clients and too loose for the non-NDK
clients. For the former, this completely hides the APIs that are newer
than the min sdk version (__ANDROID_API__). For the latter, a call to
such an API can be made without being guarded.
This change is the first step towards a better way of handling the
native APIs availability. The plan is that every NDK APIs are annotated
with the availability attribute and callers are required to guard their
API calls with a runtime check if the API is newer than the min sdk
version of the caller.
In this change, the macros now emits the availability attribute for the
non-NDK clients (i.e. when not processed by versioner).
Bug: 163288375
Bug: 134795810
Test: m
Change-Id: I6eb2bce2bc2770cbfd69815e6816b6f25b3d6127
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
The current libunwind.a LLVM prebuilt lacks the special arm64 signal
frame unwinder (https://reviews.llvm.org/D90898), so disable the signal
frame unwinding tests temporarily. (It's not clear who needs this
functionality on Android -- typically crash dumping should use
libunwindstack instead of _Unwind_Backtrace.)
Bug: http://b/153025717
Test: bionic unit tests
Change-Id: I36644dfe4acbedd937768c3aaaad1010099d602c
These were only available internally via android_mallopt(), but they're
likely to be needed by more code in future, so move them into mallopt().
This change leaves the android_mallopt() options for now, but I plan on
coming back to remove them after I've switched the handful of callers
over to mallopt() instead.
Bug: http://b/135772972
Test: treehugger
Change-Id: Ia154614069a7623c6aca85975a91e6a156f04759
These two options allow for ARM MTE to be enabled dynamically (instead
of at compile time via the ELF note). They are settable from a non-root
shell to allow device owners to test system binaries with MTE.
The following values may be set:
1. 'off' -> No MTE, uses TBI on compatible devices.
2. 'sync' -> SYNC MTE.
3. 'async' -> ASYNC MTE.
The following methods can be used to launch a process (sanitizer-status)
with configurable values:
1. adb shell MEMTAG_OPTIONS=async sanitizer-status
2. adb shell setprop arm64.memtag.process.sanitizer-status async && \
adb shell sanitizer-status
Note: The system server will require some special handing in the zygote
pre-fork to check the sysprops. The zygote should always have the ELF
note. TODO in a subsequent patch.
Bug: 135772972
Bug: 172365548
Test: Launching sanitizer-status above using both the settings.
Change-Id: Ic1dbf3985a3f23521ec86725ec482c8f6739c182
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
Android S devices must support eBPF.
Test: builds, atest, TreeHugger
Bug: 167500195
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I84a8d00f786fca8113dd3d555af279a1029f66f2
Now that the feature guarded by this flag has landed in Linux 5.10
we no longer need the flag, so we can remove it.
Bug: 135772972
Change-Id: I02fa50848cbd0486c23c8a229bb8f1ab5dd5a56f
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
I realize that we can probably clean up more of our half-forked code by
reusing the same *-compat.h headers we use for the clean upstream code,
but I'll come back and do that later.
Bug: http://b/177003648
Test: treehugger
Change-Id: I081255aaafd62718b85956c5502911a1cc80225d
Technically, std::atomic does not have an operator(). Previously, this
code was relying on an implicit behavior of our C++ standard library in
order to compile. When compiling this code against a different C++
standard library, I encountered a compiler error on these lines.
This CL makes the std::atomic load() operation explicit, makes it
clearer what this code is actually doing and makes it conform better to
the C++ standard library spec rather than a particular implmentation.
Change-Id: I7f255dffc0a3d8e07c973c18e9ba4098c4b5843e
Technically, C requires that all source files end with a newline. In
practice, most compilers will accept source files without a newline, but
it does trigger the -Wnewline-eof warning.
Change-Id: I64a92b82f4d5724cd8b45821cfd59eb3de39514b
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
