While studying the implementation of POSIX pthread_rwlock* functions, I noticed
that two functions were marked __always_inline twice. "They must really mean it
this time."
Also add back `inline` keyword to one other usage of __always_inline to be
consistent with other uses of __always_inline throughout the codebase.
Change-Id: Ibf9eaed5fc9fd03afcdd969cff82dec71a8ce30f
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-6.8
Test: Builds and bionic unit tests pass on raven.
Test: Able to log in to an Android GO 32 bit device.
Change-Id: I0022cdb20c19726f526acaab2866f1e25794b77e
Mainly just factoring out the code, but there are two functional
changes here too:
1. The inline assembler was missing `volatile`, making the hwcap
check ineffective (because the compiler would sometimes move the
MIDR_EL1 read above the hwcap check).
2. The previous code accepted variants 0x0 to 0x5 while the comment
said 0x1 to 0x5. The comment was correct.
I resisted the temptation to actually have a table to search on the assumption that it'll be a while before we need such a thing.
Bug: https://issuetracker.google.com/330105715
Change-Id: I9fdc1e70e49b26ef32794b55ca5e5fd37f1163f9
Historical code still uses this, and people work around its absence
locally. All of iOS/macOS and musl/glibc have this.
Change-Id: I119834f535b346275be5fa1df3c323eee9e242cc
Platform and future NDK releases will have no PAGE_SIZE by default,
unless __BIONIC_DEPRECATED_PAGE_SIZE_MACRO is specified.
This ensures that when people use these headers with non-standard build
systems, they will still become aware of the changes.
Bug: 312546062
Test: build/boot
Change-Id: I29f5de2cd5d59d3cefdd45a6da1ccdd7c12f1f19
LINE_MAX is a bad idea from the 1970s that we've ignored until now,
but there's already one hack in the AOSP tree (external/ltp) to work
around its absence, and kselftests would need another. Both uses are
bad code, but bad code exists, and iOS/macOS and musl/glibc all have
the same 2048 value, and it is in POSIX, so at least it's consistent
idiocy. Hopefully we're not encouraging more of it!
Bug: https://github.com/llvm/llvm-project/issues/88119
Change-Id: Ief219c3fe20b3d95da7040c4b9411f997b1c0470
Use recoverable mode for system processes and system apps as well.
Given we're a sampled bug detector anyway, why not let these processes
continue. This might save some user experience if something ends up
crashing that requires a SysUI reboot (like system_server). And, hey,
starting up processes is expensive.
Bug: N/A
Test: atest CtsGwpAsanTestCases
Change-Id: Ia6be4fcf3b3ed55a3089587d060aba7ab318cf97
The current external/libcxx uses the pthreads API to access EH globals,
which is unlikely to work in the loader. The new libc++ prebuilt uses
ELF TLS, which also doesn't work in the loader and crashes the arm64
loader on startup.
Bug: http://b/332594828
Test: treehugger
Change-Id: Icf40085d78cbaba751a97a1d457cb6cc7af7e065
The address of contents is only guaranteed to be aligned to 4KB on
4KB page size systems, but the compiler was generating code that
assumed it to be aligned to 64KB, which broke on a 4KB page size
system. This probably ought to be fixed, either in the compiler so
it can't generate code assuming such large alignments (it's hard to
see what useful optimizations are possible by assuming such large
alignments anyway) or by making bionic respect the p_align field in
PT_LOAD, but for now let's hide the address behind an asm statement
that the compiler can't see through.
As a result of this change, the code generation for the function
__bionic_setjmp_cookie_get on x86 changed so that it clobbers ecx,
as allowed by the calling convention. However, the x86 assembly
implementation for setjmp was assuming that it wouldn't be
clobbered. Fix it.
Bug: 332534664
Change-Id: I07fa737d8cf892d27ce08c305dafb0a53fef36cb
It would be nicer to do this in the build system properly, and skip
linking scudo altogether when using HWASan, but this workaround is
almost as good, so we should submit this for now.
Test: CtsWrapHwasanTestCases
Change-Id: If38df37daadae93b8979279dce7f2c9cc5bc03f8
Previously, on RISC-V, the static hwcap variable in
__bionic_call_ifunc_resolver resulted in a call to __cxa_guard_acquire,
which used a GOT access to __stack_chk_guard, but the GOT hadn't yet
been initialized. Fix this problem by applying RELR relocations
earlier.
Bug: http://b/330725041
Test: lunch aosp_cf_riscv64_phone-trunk_staging-eng; boot device
Change-Id: Ib10fdcc0d2c1b875eba6bc5e0115a6768d6f25ee
Some obfuscated ELFs have PT_NOTE headers that are past the end of the
file. Skip parsing these for crt_pad_segment note, as accesses beyond
the file will cause a SIGBUS.
Bug: 331717625
Test: Manual - Launch Guns up app
Change-Id: I39365064e6c1538b0be1114479557d94a72ee369
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Submitted on behalf of a third-party: Linaro Limited
License rights, if any, to the submission are granted solely by the
copyright owner of such submission under its applicable intellectual
property.
Copyright (c) 2012, Linaro Limited
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the Linaro nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Origin Project URL: https://android.googlesource.com/platform/bionic/
Commit ID: 7e4fa56099
Third Party code includes additions/modifications from Qualcomm Innovation Center, Inc.
Test: All
Change-Id: I479a572a325e27262d27aa37c516618e4322e9bb
Submitted on behalf of a third-party: Arm Limited
License rights, if any, to the submission are granted solely by the
copyright owner of such submission under its applicable intellectual
property.
Copyright (c) 2012-2022, Arm Limited.
SPDX-License-Identifier: MIT OR Apache-2.0 WITH LLVM-exception
Origin Project URL: https://github.com/ARM-software/optimized-routines
Tag: v24.01
Third Party code includes additions/modifications from Qualcomm Innovation Center, Inc.
Test: All
Change-Id: I0c97398a435e3f8ddf8ad38bc6bd71cc0d78aea5
Newer versions of lld write ifunc relocations for PLT entries
to .rela.dyn instead of .rela.plt. This causes a problem because
.rela.dyn is subject to Android relocation packing and we don't
support relocation packing when calling the linker's own ifunc
resolvers. Resolve the problem by passing --pack-dyn-relocs=relr
which disables Android relocation packing but keeps RELR packing
enabled which covers most of the relocations in the linker.
With the current toolchain there are only two entries in the linker's
.rela.dyn (and these entries look like a bug anyway) so there should
be no substantial change to binary size as a result of this change.
Relocation section '.rela.dyn' at offset 0x8e8 contains 2 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
00000000001691d8 0000000100000401 R_AARCH64_GLOB_DAT 0000000000000000 ZSTD_trace_decompress_begin + 0
00000000001691e0 0000000200000401 R_AARCH64_GLOB_DAT 0000000000000000 ZSTD_trace_decompress_end + 0
Bug: 331450960
Change-Id: Idf403e775d134cbe208d6b1635a84a2a3e70b74b
It's especially unhelpful of us to say things like "U" given that marketing switched the public back to numbers.
Change-Id: I7fb9e30667fbf9830bc71319dcca18e92d064522
