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
In native build of libc it would be inlined and in native bridge mode
it's noinline, extern "C" and thus could be easily intercepted.
Test: m (without weak symbols in native bridge mode x86+arm build would be broken)
Change-Id: I67759858a5bc2174dce1db9732fdbd89ba7689cc
Now, when we can detect native bridge mode is sources we can do that.
Test: m (without weak symbols in native bridge mode x86+arm build would be broken)
Change-Id: I360e7df8211d03636bbe716dc14655ee8d765493
malloc_debug can use libunwind and libunwindstck to unwind backtrace,
if libc.debug.malloc.options contains the string of "backtrace_full",
malloc_debug will use libunwindstck, and if libc.debug.malloc.options
contains the string of "backtrace=*", malloc_debug will use libunwind.
The result of libunwindstck is normal, but the result of libuniwnd
is abnormal, there is a offset between the rel_cp and the correct value,
so addr2line can't decode the right line number.
Libunwind and libunbiwndpack calculate load_bias is different, so malloc_debug
get load_bias alignment with libunwindstack.
Bug: 169539402
Change-Id: I640fb5db39af622a0bb52abf2c107984065a89d5
* changes:
libc: Add Armv8.3-A PAuth and Armv8.5-A BTI compatibility to *.S
Update crtbegin.c and crt*.S to support Armv8.5-A BTI
libm: Add Armv8.3-A PAuth and Armv8.5-A BTI support to assembly files
libc: Prepare support for Armv8.3-A PAuth and Armv8.5-A BTI in *.S
The latest LLVM update to r399163 has exposed an issue with optimization
of `aligned_alloc()` at -O2. Invalid inputs are treated as valid, which
results in assertions being hit. This WAR is to make sure that the test
keeps running while we fix the issue upstream.
Bug: http://b/169206016
Bug: http://b/155835175
Test: atest malloc_hooks_system_tests:malloc_hooks_system_tests.MallocHooksTest#aligned_alloc_hook_error -- --abi x86
Change-Id: I74b290b73826481c62db3a99ac1a690c8a8a8db3
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
This is really just a case of including the proper header for a
function.
Bug: http://b/155835175
Test: OUT_DIR=out prebuilts/clang-tools/build-prebuilts.sh
Change-Id: I0523d3ccd8cb502e8c2b8f72f137db4b60fb1dac
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
android_filesystem_config.h is found since system/core/include is on
the include path for all projects and contains a symlink to the real
android_filesystem_config.h. This is fragile and the below bug seeks
to remove this symlink and have users correctly depend on
libcutils_headers.
In bionic, libcutils_headers header library cannot be used due to
cyclic dependencies, so it gets the actual include path instead, which
is less bad than depending on the build system injecting the for all
modules.
Bug: 165825252
Test: build
Change-Id: Id43bdea9553b1174ceb3efc2a3ed505888619c62
It was originally based on fdlibm, but it's been through two different
projects since then, and `git blame` shows basically nothing remaining
from those days. Seems worth leaving something to explain the unusual
copyright header though!
Test: treehugger
Change-Id: I8e7252a755704b866e7f36c8e97adc021fa3cdad
This value indicates whether memory tagging is enabled on a thread,
the mode (sync or async) and the set of excluded tags. This information
can sometimes be important for understanding an MTE related crash,
so include it in the per-thread tombstone output.
Bug: 135772972
Change-Id: I25a16e10ac7fbb2b1ab2a961a5279f787039000b
This is already covered by the existing test by virtue of being used for
all threads.
Bug: http://b/168258494
Test: treehugger
Change-Id: I5c872fd7f30a4c79de1d70e7702f4b12d4e94cd3
An upcoming change to Scudo will change how we use the TLS slot
in tsd_shared.h, which will be a little easier to deal with if
we can remove the code path that calls pthread_getspecific and
pthread_setspecific. The only known user of this code path is Fuchsia.
We can't eliminate this code path by making Fuchsia use ELF TLS
because although Fuchsia supports ELF TLS, it is not supported within
libc itself. To address this, Roland McGrath on the Fuchsia team has
proposed that Scudo will optionally call a platform-provided function
to access a TLS slot reserved for Scudo. Android also has a reserved
TLS slot, but the code that accesses the TLS slot lives in Scudo.
We can eliminate some complexity and duplicated code by having Android
implement the same mechanism that was proposed for Fuchsia, which is
what this change does. A separate change to Scudo will make use of it.
Bug: 163630045
Change-Id: I4678105c9c47a23feb5a5e80a314416de4556d9c
Linkerconfig is going to remove all hard-coded dependencies from APEX
modules and let APEX modules specify its own requirements. As part of
it, this change adds a new configuration file for linkerconfig and let
it aware that bionic APEX should be visible from all sections.
Bug: 167946001
Test: atest passed
Change-Id: If934d9a3e72b1466ee0d7bbb66d9383b90986a6b
Except they are the same on arm32/arm64, so we hadn't really noticed. x86
and x86-64 are quite different though, presumably by historical accident.
Fix the definitions and add some static asserts.
Bug: https://github.com/android/ndk/issues/1347
Test: treehugger
Change-Id: Ic27b172066cf3443749463b9b73c912d204f9516
The most notable change is in sigsetjmp/siglongjmp. The former
stores LR signed with the current SP into jmp_buf. Calling siglongjmp
reads a signed LR and the corresponding SP from jmp_buf. This way not
only the checksum provides some means of integrity protection but
Pointer Authentication too.
Test: Tested on FVP with BTI enabled.
Change-Id: I9d720239775f8d2829a677901f546c4b14b5cbe5
These files are linked to all ELF files therefore they must support BTI.
Test: Tested on FVP with BTI enabled using a patched clang.
Co-authored-by: Gabor Kertesz <gabor.kertesz@arm.com>
Co-authored-by: Daniel Kiss <daniel.kiss@arm.com>
Co-authored-by: Tamas Petz <tamas.petz@arm.com>
Change-Id: If5df0722e649bcdb8c4afb0531831dff42103c9c
This change adds both Armv8.3-A Pointer Authentication and Armv8.5-A BTI
support to *.S files.
Tests: Tested on FVP with BTI enabled
Change-Id: I82750afcbc950a91584463fbc979c2c35d41916a
The instruction "bti c" is added through ENTRY*() macro,
using __bionic_asm_custom_entry(f).
The .note.gnu.property section is added with the new macro
NOTE_GNU_PROPERTY(). BTI and PAuth features are automatically
selected based on the presence of __ARM_FEATURE_* macros.
Furthermore, gensyscalls.py got updated to append the new
macro to the generated syscalls-arm64.S.
Test: Tested on FVP with BTI enabled.
Change-Id: I40ffe294b8426421125fffd0a9758567d919a09d
This benchmarks mapping property prefixes to property contexts with
two algorithms: the 'Legacy' method used before Android P and the
'Trie' used afterwards (the code in this directory).
It uses input mappings from both Oreo and the latest in AOSP ('S').
Note that there is nearly a 10x increase in the number of mappings in
S as there was in Oreo, which was predicted when the trie was
designed.
Results on cuttlefish:
-----------------------------------------------------------
Benchmark Time CPU Iterations
-----------------------------------------------------------
LegacyLookupOreo 683576 ns 673538 ns 1060
LegacyLookupS 5683109 ns 5596982 ns 124
TrieLookupOreo 299851 ns 295696 ns 2378
TrieLookupS 584831 ns 576801 ns 1204
The results show that the legacy look up uses 8.3x more CPU time to
handle the number of mappings added through S, whereas the Trie lookup
uses less than 2x more CPU time, showing that the trie scales better
with added mappings.
Test: run this benchmark
Change-Id: I35c3aa4429f049e327a891f9cbe1901d8855d7ba
