The maximum page size Android supports
now is 16384, and Art only supports 16kB,
so we can save a bit of space.
Bug: 332556665
Test: N/A
Change-Id: I23df607bcc5cf9e96d7b6a66169413cd1a883f7e
Rather than only updating the maps when a pc can't be found, always update
the maps before using them. This avoids issues where the maps change
and it could cause a crash reading from a map that has been modified.
This assumes that executed code never gets unloaded, or that the
code is unloaded so infrequently that it doesn't matter. This happens
because the pcs for the backtraces are gathered as the program runs
and those pcs are symbolized and made into relative pcs at a later time.
Also, add safe reading of the elf data when necessary to avoid any
crashes if maps are changing while this is running.
Since the MapEntry objects can be deleted, copy the values for
the current map in the backtrace code to detect when in our own code
instead of keeping a pointer.
Bug: 340988785
Test: malloc_debug unit/system tests pass.
Test: libmemunreachable tests pass.
Change-Id: Ica2ba50a5bcf9e19c7e4033e29a5a67a1847d1a6
We do the same thing in pthread_create().
This has the nice side-effect of letting us move part of the child setup that we were doing in the parent into the child where it belongs.
Bug: https://issuetracker.google.com/340125671
Change-Id: Ibe646d5ca9066f487d08fd40f004550349e8a02e
This makes this TraceFunction() more like trace_function() in malloc_debug. I'll leave whether we can collapse these into one implementation as an open question for now...
Change-Id: I3981e4114244d49f8dbae1d3b776a7e9c32be688
I was only here to stop saying "Android R", which doesn't mean much to most app developers, but while I'm here...
Change-Id: I0ffd5d679747491d338064e36efc80b2b82e9e06
We can (and should) use `inline` in C++ but not in C headers that
need to support ANSI/C89/C90. `__inline__` works everywhere, but
traditionally we've used the BSD `__inline` in public headers.
Change-Id: I920e0a1f5fcd01cf8ddd89240ef66b25c50378d7
This reverts commit 58f06e1112.
Bare `inline` is not ANSI C compatible, and NDK users may be using
that.
Test: treehugger
Change-Id: I82c5424522142001cd59da63ef3fd440014451ad
A change in scudo changed to lazy allocation of the ring buffer,
so we need to update the globals once we enable stack trace collection
Bug: 339020123
Test: sanitizer test app
Change-Id: Ideda7b761e75052d09df27de1f6b04aeb9a03dc2
The previous names were difficult to decipher. Now, let's change this
all to be more clear as it's actually one android_mallopt() call
depending on where it's called from, rather than the intended behaviour.
Also updated the comments so it's clear what happened across different
versions of Android.
Test: atest bionic-unit-tests CtsGwpAsanTestCases
Bug: N/a
Change-Id: I0582cab0b74aa09f4af54f9fbe5ba22697f82082
... so that it can be used by fs_config_[dirs|files] genrules.
Previously, the fs_config_* were created by Android.mk and capability.h
was referenced directly from there. Since Soong doesn't allow that,
let's export the file explicitly.
Bug: 337993745
Test: m
Change-Id: I2777a4dbe6b977bc64c5f6defe748fa7993e578e
I'll land another patch that makes this required once I've fixed up
all the callers.
Bug: https://github.com/android/ndk/issues/2014
Test: treehugger
Change-Id: I62b9fdd3174f37d33f01c27f7f4e9134f6d9df6e
Failure to add a property should be rare, so log the specific
failure to aid in debugging.
Bug: http://b/322714325
Change-Id: I9461428f16d7d04d5aceb910a5cf1c928cfe9da2
The malloc_not_svelte product variable has been removed and is
replaced by malloc_low_memory. This switches the sense of the
Test: Verified scudo config is used by default.
Test: Verified Android GO config uses the jemalloc low memory config.
Test: Verified that the default config on oriole produces the exact same
Test: libc.so with and without this change.
Change-Id: I48085fa6c2dcf5c61f847ef1f15c38653d1f7214
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
We cannot use a WriteProtected because we are accessing it in a
multithreaded context.
Test: atest memtag_stack_dlopen_test w/ MTE
Test: atest bionic-unit-tests w/ MTE
Test: atest bionic-unit-tests on _fullmte
Bug: 328256432
Change-Id: I39faa75f97fd5b3fb755a46e88346c17c0e9a8e2
We would get the SP inside of memtag_handle_longjmp, which could prevent
us from detecting the case where a longjmp is going into a function that
had already returned. This changes makes the behaviour more predictable.
Change-Id: I75bf931c8f4129a2f38001156b7bbe0b54a726ee
