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
Set PTHREAD_STACK_MIN will be set to:
- 16384 for 64-bit arch
- 8192 for 32-bit arch
Bug: 315174209
Test: Built and start the targets
- aosp_cf_arm64_phone_pgagnostic
- aosp_cf_x86_64_phone
Change-Id: I8bb20a3433e615f9f80a0d52051f2e1635d4301a
This reverts commit ef867550ac.
Reason for revert: a change to a python script run as a commit hook cannot cause a golang crash during builds.
Change-Id: Id63d4ea370e36f890a140b9e1bc69482e3610c42
This reverts commit adb8af2668.
Reason for revert: DroidMonitor: Potential culprit for Bug 315240955 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
BUG: 315240955
BUG: 315240463
Change-Id: I9f7297c6ca48728a91f7f4640ac19f901effb3cc
I don't think we need this, and we're not doing it for the equivalent
code in riscv64. So either we do need it, and this will help us find out
quicker and make the corresponding riscv64 change, or we don't need it,
and this is a free cleanup.
Test: treehugger
Change-Id: Ie97492ea8bb4d1bc69f926980d9d4db798884285
This way, callees don't need to worry about whether or not their
reference to __riscv_hwprobe() has been resolved before their ifunc
resolver is called.
This matches the current glibc proposal from rivos.
Test: treehugger
Change-Id: I0d5244aa837d0d1f0e6bd7d22091dfedb8a55bdb
There is no need to use PAGE_SIZE to define the value of
PTHREAD_STACK_MIN.
Bug: 312546062
Bug: 313941999
Test: source build/envsetup.sh
lunch aosp_cf_arm64_phone_pgagnostic-trunk-userdebug
m
Change-Id: If3c3fe39f50592df58634d1c164e87dcd0aebad0
This works out a bit silly/ugly because the bits/ header file has the
wrong name, so I've also changed the map from kernel struct to boolean
to be a map from kernel struct to filename. That not only fixes this,
it's a bit more readable too. (Just yesterday, when I had no real reason
to change it, I was asking myself "why is this a boolean?"!)
Bug: http://b/236042740
Test: treehugger
Change-Id: I3eee25b493ea97d46cc5dc5fde07f7c5e77d2a46
This is a no-op but will be used in upcoming scudo changes that allow to
change the depot size at process startup time, and as such we will no
longer be able to call __scudo_get_stack_depot_size in debuggerd.
We already did the equivalent change for the ring buffer size in
https://r.android.com/q/topic:%22scudo_ring_buffer_size%22
Bug: 309446692
Change-Id: Icdcf4cd0a3a486d1ea07a8c616cae776730e1047
Symlinks were previously able to escape the genrule sandbox, but
after aosp/2850015 they can't.
Instead of a symlink, just use the fs_config_generator soong module.
Bug: 307824623
Test: generated_android_ids
Change-Id: Ifcd9eb06c46181903ff57713132940939d5facf6
No-one's hit this in practice, that I know of, but there are very few
instances of this old workaround for kernel/userspace mismatches still
present, and (as part of the much harder and less effective `struct
sigaction` cleanup), we should just remove them.
Bug: http://b/236042740
Test: treehugger
Change-Id: I6c71d4353044cf57cfa8a9796a4c3d6a4d51cd86
Before this change, we have the kernel's sigaction in the uapi headers,
and our own sigaction in <bits/signal_types.h> and we rely on callers
making sure to use `#define` to move the kernel type out of the way if
they include a uapi header directly. This is obviously error-prone and
undesireable, and not what we usually do now.
What we _usually_ do now is use the header scrubber's ability to replace
a struct definition with a `#include <bits/STRUCT.h>`, but that doesn't
work here because struct sigaction relies on a lot of other types,
some of which also come from uapi headers.
So instead use our second best trick, which is to "move the kernel struct
out of the way" at header scrubbing time instead. This means that someone
who does `#include <linux/signal.h>` or `#include <asm/signal.h>` won't
get `struct sigaction` (they'll only have `struct __kernel_sigaction`
instead), but it does mean that they can't get two incompatible
definitions if they include a uapi header both directly and indirectly.
So although this doesn't do what I'd set out to do, it's still an
improvement in some cases, and it's our preferred idiom in most cases
anyway. (I'll come back once this is in to tidy up the two other kernel
structs where we're still using the deprecated "rename out of the way
using #define" trick, but this change is already hairy enough, and
there's a possibility it will break code that didn't care that it was
getting the kernel `struct sigaction` rather than the userspace one.)
Bug: http://b/236042740
Test: treehugger
Change-Id: Icff50e330c09c587e8f77ba0fb7cffffd9c3b708
We'll probably never hit this (because the case I hit it with, struct
sigaction, isn't amenable to the "replace with #include <bits/STRUCT.h>"
trick), but in case we do, and because a set expresses our intent better
than a list, keep the list^Wset of generated includes in a set.
Bug: http://b/236042740
Test: treehugger
Change-Id: I21f5c08515eab1b28e6a36fc00149b6bc7740b7e
Adding the new option log_allocator_stats_on_signal that will call
mallopt(M_LOG_STATS, 0), when a signal is sent to a process.
This call does not happen in the signal handler, but a variable
is set to trigger the mallopt call. The next time any allocation
call occurs, the mallopt call will be made.
Also, includes new unit tests for the new config option.
Test: All unit tests pass.
Test: Enabling the new feature and stop/start and sending the signal to
Test: a process and observing the log contains the memory stats.
Test: Did the above for a scudo and jemalloc based device.
Change-Id: Idcf6fca74036efb065b9c4cc037aaf9bcf0f139e
