This attribute had been commented out since it was first
committed a decade ago. No-one's going to chase down arm32-only
trivia like that before arm32 and x86 are removed as obsolete...
Change-Id: I8e29d16657b3f4ce379e65732d747f969ea31dae
We should just be able to use __builtin_umull_overflow now, which expects
unsigned long parameters. We don't need __builtin_umul_overflow (which expects
unsigned ints) because Bionic is LP64 or ILP32, so for ILP32
sizeof(size_t) == sizeof(unsigned long),
so __builtin_umull_overflow will work for either ILP32 or LP64.
Test: mm
Change-Id: I872491731bca05e561767f8bfeda4c6704e10ccb
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
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 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
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
See code comments for details. I think everything we could reasonably
upstream from this file is now an upstream pull request. If they get in,
I'll try my luck with the arm32 TLS constant (which is a bit more
interesting because there's a probably obsolete conflict upstream, but
someone who knows about FreeBSD/arm32 would want to look at that).
Test: treehugger
Change-Id: I5bf197045940d25efb2a520716499d924c362b57
Not useful right now, but Qualcomm has an Oryon memset they'd like to
use, and there's no reason to treat memrchr as a weird special case.
Bug: https://issuetracker.google.com/330105715
Test: treehugger
Change-Id: Id879479bf4f45433debcb3fe08cfa96bb1eb3b93
RTLD_DEFAULT/RTLD_NEXT already linked to the functions, but the functions should link to the constants too.
Change-Id: I854b632092f077d71918e99b3caec874e1df1ef3
Looks like I'd been bad here, and added new stuff to this file rather
than <elf.h> directly. I've also done nothing to upstream any of this.
This patch at least addresses the former problem, moving our stuff out
into <elf.h>.
Rather than *delete* anything that conflicts with Linux in elf_common.h,
I've disable it with // or #if, and marked those as Android changes to
make it less likely that the next update accidentally drops them (which
isn't super likely, since most of them should actually cause build
failures when they conflict with uapi).
Test: treehugger
Change-Id: Id0deccc7305c60b0f708b55e2eed0dedc0bca41d
arm32/arm64: Previously, the loader miscalculated a negative value for
offset_bionic_tcb_ when the executable's alignment was greater than
(8 * sizeof(void*)). The process then tended to crash.
riscv: Previously, the loader didn't propagate the p_align field of the
PT_TLS segment into StaticTlsLayout::alignment_, so high alignment
values were ignored.
__bionic_check_tls_alignment: Stop capping alignment at page_size().
There is no need to cap it, and the uncapped value is necessary for
correctly positioning the TLS segment relative to the thread pointer
(TP) for ARM and x86. The uncapped value is now used for computing
static TLS layout, but only a page of alignment is actually provided:
* static TLS: __allocate_thread_mapping uses mmap, which provides only
a page's worth of alignment
* dynamic TLS: BionicAllocator::memalign caps align to page_size()
* There were no callers to StaticTlsLayout::alignment(), so remove it.
Allow PT_TLS.p_align to be 0: quietly convert it to 1.
For static TLS, ensure that the address of a TLS block is congruent to
p_vaddr, modulo p_align. That is, ensure this formula holds:
(&tls_block % p_align) == (p_vaddr % p_align)
For dynamic TLS, a TLS block is still allocated congruent to 0 modulo
p_align. Fixing dynamic TLS congruence is mostly a separate problem
from fixing static TLS congruence, and requires changing the dynamic
TLS allocator and/or DTV structure, so it should be fixed in a
later follow-up commit.
Typically (p_vaddr % p_align) is zero, but it's currently possible to
get a non-zero value with LLD: when .tbss has greater than page
alignment, but .tdata does not, LLD can produce a TLS segment where
(p_vaddr % p_align) is non-zero. LLD calculates TP offsets assuming
the loader will align the segment using (p_vaddr % p_align).
Previously, Bionic and LLD disagreed on the offsets from the TP to
the executable's TLS variables.
Add unit tests for StaticTlsLayout in bionic-unit-tests-static.
See also:
* https://github.com/llvm/llvm-project/issues/40872
* https://sourceware.org/bugzilla/show_bug.cgi?id=24606
* https://reviews.llvm.org/D61824
* https://reviews.freebsd.org/D31538
Bug: http://b/133354825
Bug: http://b/328844725
Bug: http://b/328844839
Test: bionic-unit-tests bionic-unit-tests-static
Change-Id: I8850c32ff742a45d3450d8fc39075c10a1e11000
We're starting to see projects _only_ use the SPDX identifiers (and
they're more readable "at a glance" anyway), so it's probably time to
include these...
Test: N/A
Change-Id: I5c76d77dcd392a8db1166108e410389d349a42c3
Vendor modules do not follow bionic versioning but define their own
versioning for LLNDK. Ignore the __INTRODUCED_IN annotation for
vendor modules.
Bug: 302113279
Test: build trunk-staging and next configurations
Change-Id: I04646b524d17f7ae47f0f96cb98f221f3e821629
