Fix the issue if link for an symlink that point to an relative path
cause the linker can not find the right absolute path.
For example:
lrwxr-xr-x 1 root shell 13 2009-01-01 08:00 /system/bin/app_process -> app_process64
the '/system/bin/app_process' is symlinked to 'app_process64' and will be failed.
if the 'exe_to_load' is null and also failed when stat '/proc/self/exe'
will entered this path.
Without Patch:
[ Linking executable "app_process64" ]
linker: CANNOT LINK EXECUTABLE "/system/bin/app_process": library "libnativeloader.so" not found: needed by main executable
With Patch:
[ Linking executable "/system/bin/app_process64" ]
[ Using config section "system" ]
[ Jumping to _start (0x75593c3000)... ]
Test: Manual - Run app_process (symlinked to app_process64)
Change-Id: Iacd0a810a679e8d55d68d7e4c84f0e5e4f276b14
Signed-off-by: chenxinyuanchen <chenxinyuanchen@xiaomi.com>
Signed-off-by: chenxinyuanchen <chenxinyuanchen@xiaomi.corp-partner.google.com>
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 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