llvm-libc will reuse parts of the existing system headers for types that have
implications on the ABI.
Fixes:
error: external/llvm-libc/Android.bp:3:1: module "llvmlibc" variant
"android_recovery_riscv64_static": depends on //bionic/libc:libc_headers
which is not visible to this module You may need to add
"//external/llvm-libc" to its visibility
Test: TH
Bug: 321313756
Change-Id: I33b93d8e1617a480249641dc2cdf4bbee9f9e19d
These files were segregated because they were lacking a little cleanup.
Unfortunately that means this change has to do some of the cleanup, but
that's probably for the best.
Test: treehugger
Change-Id: I2dd33504787fc3313995de99e0745a0df22915b3
This reverts commit 79c9694c91.
Reason for revert: DroidMonitor: Potential culprit for Bug b/324348078 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: I32f7bc824900e18a7d53b025ffe3aaef0ee71802
Factor out generic __get_elf_note() logic and rename __get_elf_note() to
__find_elf_note(). Expose __get_elf_note() in libc/private/bionic_note.h
This will be used in the subsequent patch to test the presence of
NT_ANDROID_TYPE_PAD_SEGMENT note when loading segments.
Test: atest -c linker-unit-tests [Later patch]
Test: m && launch_cvd
Bug: 316403210
Change-Id: Ia7cb2f40b10cfaef402182a675087c8422b37e4d
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
BYPASS_INCLUSIVE_LANGUAGE_REASON="man" refers to manual not person
Bug: 318749472
Test: atest pthread on MTE enabled device
Test: atest memtag_stack_dlopen_test on MTE enabled device
Test: manual with NDK r26b built app with fsanitize=memtag-stack
Change-Id: Iac191c31b87ccbdc6a52c63ddd22e7b440354202
This CL is created as a best effort to migrate test targets to the new Android ownership model.
It is based on historical data from repository history and insights from git blame.
Given the nature of this effort, there may be instances of incorrect attribution. If you find incorrect or unnecessary
attribution in this CL, please create a new CL to fix that.
For detailed guidelines and further information on the migration please refer to the link below,
go/new-android-ownership-model
Bug: 304529413
Test: N/A
Change-Id: Ie36b2a3245d9901323affcc5e51dafbb87af9248
The motivation for these is long gone, and now they only serve to
distract/duplicate.
Test: treehugger
Change-Id: I28f4ea6dd02fb564a15ab23b9f70d447ddf0c090
In particular: 32-bit x86 doesn't need sa_restorer either.
I still don't fully understand why arm32 and x86-64 do, so I've left the
comments in those .S files alone. I haven't (knowingly) tested
compiler-rt since we switched from libgcc (which is what the comments
refer to), but I have tested libunwindstack since we switched from
libunwind, and that does fail existing bionic tests for unwinds through
signal frames --- I just don't know why, or whether there's a better fix.
Anyway, local testing suggests that the 32-bit x86 code is vestigial, so
let's get rid of it.
Test: treehugger
Change-Id: I3e2616f736d27a8463814356e5adb52fd76a90cc
clang complains if you define a symbol and _then_ make it weak, rather
than the other way round:
/tmp/setjmp-c3c977.s:90:1: warning: sigsetjmp changed binding to STB_WEAK
.weak sigsetjmp;
^
Test: treehugger
Change-Id: Iee6b0ea456bb2e92aea810ce45f171caabaa89d2
I haven't seen this cause a problem in practice --- I noticed this while
looking at something else entirely.
Test: llvm-objdump
Change-Id: I56e38165f45554ede538a50439f8e8ffe72871c8
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-6.7
NOTE: The file bionic/libc/kernel/uapi/linux/usb/f_accessory.h was
deleted in the 6.7 kernel along with the functionality. However,
there is no current replacement. For now keep the file here, but at
some point when the new implementation is ready, this file will need to
be moved to the places that still need to be backwards compatible.
Test: Builds and bionic unit tests pass on raven.
Test: Able to log in to an Android GO 32 bit device.
Change-Id: Ibf5684ed140616c02bb9464bbd6422a9281a29cf
crt_pad_segment provides a note of type NT_ANDROID_TYPE_PAD_SEGMENT.
It's intended when present is for the loader to pad segment gaps to
reduce kernel slab memory usage (due to additional vm_area_struct's
for gaps). crt_pad_segment.o retains control to the static linker so
that app developers can opt out (build with different flags) it there
are undesireable side effects.
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .strtab STRTAB 0000000000000000 0000f8 000066 00 0 0 1
[ 2] .text PROGBITS 0000000000000000 000040 000000 00 AX 0 0 4
[ 3] .note.GNU-stack PROGBITS 0000000000000000 000040 000000 00 0 0 1
[ 4] .note.android.pad_segment NOTE 0000000000000000 000040 00001c 00 A 0 0 4
[ 5] .rela.note.android.pad_segment RELA 0000000000000000 0000e0 000018 18 I 7 4 8
[ 6] .debug_line PROGBITS 0000000000000000 00005c 000052 00 0 0 1
[ 7] .symtab SYMTAB 0000000000000000 0000b0 000030 18 1 1 8
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), l (large), p (processor specific)
Bug: 316403210
Test: m -j50 ndk
Test: find out/soong/ndk -name 'crt_pad_segment.o'
Test: readelf -SW crt_pag_segment.o
Change-Id: I94af5e85fd602e7ba5fd56788ae39277368229d8
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
std::atomic<T>'s default constructor is no longer trivial, because it
now does value-initialization. As a result, the class is no longer
trivial, so libc_globals is no longer trivial, so it is no longer POD.
(FWIW, the "POD" notion has been deprecated in favor of "trivial" and
"standard layout" concepts: POD == trivial + stdlayout.)
See https://cplusplus.github.io/LWG/issue2334 and wg21.link/p0883r2.
Mark __libc_globals as constinit, because that seems closer to
something we actually care about, AFAICT.
Bug: http://b/175635923
Test: m libc_malloc_debug
Change-Id: I338589bce03d06f20752bca342eeb86a42fc1ee7
The libraries are
- libdl_static
- liblinker_main
- liblinker_malloc
- libsystemproperties
The availability to runtime apex was done implicitly using a baseline map in
build/soong/apex/apex.go. Make this explicit in Android.bp
Bug: 281077552
Test: m nothing
Change-Id: I029ae204f6cfef8c301a20b7c4294636b60b38be
This reverts commit 46cce48995.
Reason for revert:
Will put a change behind flags to bump storage to 1Mb for internal build only. AOSP code does not need to be changed. The change will be only made to git_main.
Change-Id: If3484d0e56f4c3d8fc729f55744c2d8ebdd13b11
While aconfig flag storage is being migrated to its own dedicated
storage, we need to provide some relief to the current flag users which
are running into storage capacity limit of system property. Currently
system property by default allocates a file of 128Kb for each storage
node. Bump it to 256Kb for now.
Bug: b/316037066
Change-Id: I8b0b58733f362c3789ec92ae09ee589c7c1b72c6
The main change here is to remember that we arm64/x86-64 have flags, and
__builtin_<op>_overflow() lets us look at them. There's a clear saving
for arm64, and x86-64 is better too, though interestingly there the
unsigned case doesn't work out as well as the signed case because both
unsigned __builtin_mul_overflow and unsigned __builtin_add_overflow are
less efficient than the signed multiply and subtract on that
architecture, but the new code still beats the old code even so.
There's a very tiny microoptimization of the hex path that takes
advantage of the fact that conversion to lowercase is a single
instruction on all our architectures when we already know we're dealing
with a letter.
This also merges the signed and unsigned variants of the code. Not
entirely successfully, but the vast majority of the code benefits.
Before (arm64):
```
----------------------------------------------------------------
Benchmark Time CPU Iterations
----------------------------------------------------------------
BM_inttypes_strtoimax 44.6 ns 44.3 ns 15807654
BM_inttypes_strtoumax 43.1 ns 42.8 ns 16348848
BM_stdlib_strtol 44.6 ns 44.3 ns 15805384
BM_stdlib_strtol_hex 85.5 ns 85.0 ns 8235487
BM_stdlib_strtoll 44.5 ns 44.2 ns 15833137
BM_stdlib_strtoul 43.1 ns 42.8 ns 16353963
BM_stdlib_strtoul_hex 83.1 ns 82.6 ns 8477732
BM_stdlib_strtoull 43.1 ns 42.8 ns 16353015
```
After (arm64):
```
----------------------------------------------------------------
Benchmark Time CPU Iterations
----------------------------------------------------------------
BM_inttypes_strtoimax 37.9 ns 37.6 ns 17657577
BM_inttypes_strtoumax 35.9 ns 35.7 ns 19597727
BM_stdlib_strtol 36.9 ns 36.7 ns 19093037
BM_stdlib_strtol_hex 70.7 ns 70.3 ns 9961626
BM_stdlib_strtoll 36.9 ns 36.7 ns 19093032
BM_stdlib_strtoul 35.9 ns 35.7 ns 19617784
BM_stdlib_strtoul_hex 67.7 ns 67.3 ns 10113521
BM_stdlib_strtoull 35.9 ns 35.7 ns 19621828
```
Test: treehugger
Change-Id: Ibf53b29e34d63ac31520c6d27ef80ff281899d61
Actually reusing the hash table stuff from the linker would be a lot of
work (and the benefit unclear for so few symbols), but we can at least
break out of loops as soon as we have what we need.
Test: treehugger
Change-Id: I9cbe4636a3e3163bd302c3676eb674a4278dbf2e
