... 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
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
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
initgroups() is just a call to getgrouplist() followed by a call to
setgroups(). The tricky part is memory allocation. OpenBSD allocates an
NGROUPS_MAX-sized array of gid_t on the stack. FreeBSD allocates a
sysconf(_SC_NGROUPS_MAX)-sized array of gid_t on the heap. bionic had a
mix where it would try a 2-element stack array but fall back to a heap
allocation, which sounds reasonable if you want to avoid a 256KiB
(64Ki*4 bytes) allocation on either stack or heap. But that constant 2?
That's weird in two ways... It's really small (musl has an NGROUPS_MAX
of 32 unlike the Linux kernel's 64Ki, but 32 is still a lot larger than
2), but at the same time it's too big --- bionic's getgrouplist() always
returns a single element.
So although the FreeBSD "what the hell, let's just allocate 256KiB on
the heap" implementation would have been fine, there's really no point,
and anyone who's trying to understand initgroups() on Android really
needs to read getgroupslist() anyway, so let's just have the most
trivial implementation -- a single-element array -- and let's have it
right next to getgroupslist() in the same file as all the other <grp.h>
functions.
Also add a trivial smoke test. You mostly won't have permission to do
anything interesting with initgroups(), and it's basically unused save
for privilege dropping tcpdump and strace, but we may as well make an
effort. (I tested tcpdump before and after too.)
Test: treehugger
Change-Id: I67fe02e309ed1dbefc490c01733738363ca606be
llvm-libc will reuse parts of the existing system headers for types that have
implications on the ABI.
Fixes:
error: external/llvm-libc/Android.bp:3:1: module "llvmlibc" variant
"android_recovery_riscv64_static": depends on //bionic/libc:libc_headers
which is not visible to this module You may need to add
"//external/llvm-libc" to its visibility
Test: TH
Bug: 321313756
Change-Id: I33b93d8e1617a480249641dc2cdf4bbee9f9e19d
These files were segregated because they were lacking a little cleanup.
Unfortunately that means this change has to do some of the cleanup, but
that's probably for the best.
Test: treehugger
Change-Id: I2dd33504787fc3313995de99e0745a0df22915b3
Factor out generic __get_elf_note() logic and rename __get_elf_note() to
__find_elf_note(). Expose __get_elf_note() in libc/private/bionic_note.h
This will be used in the subsequent patch to test the presence of
NT_ANDROID_TYPE_PAD_SEGMENT note when loading segments.
Test: atest -c linker-unit-tests [Later patch]
Test: m && launch_cvd
Bug: 316403210
Change-Id: Ia7cb2f40b10cfaef402182a675087c8422b37e4d
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
The motivation for these is long gone, and now they only serve to
distract/duplicate.
Test: treehugger
Change-Id: I28f4ea6dd02fb564a15ab23b9f70d447ddf0c090
In particular: 32-bit x86 doesn't need sa_restorer either.
I still don't fully understand why arm32 and x86-64 do, so I've left the
comments in those .S files alone. I haven't (knowingly) tested
compiler-rt since we switched from libgcc (which is what the comments
refer to), but I have tested libunwindstack since we switched from
libunwind, and that does fail existing bionic tests for unwinds through
signal frames --- I just don't know why, or whether there's a better fix.
Anyway, local testing suggests that the 32-bit x86 code is vestigial, so
let's get rid of it.
Test: treehugger
Change-Id: I3e2616f736d27a8463814356e5adb52fd76a90cc
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
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>
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
Right now, the unwinder doesn't support compressed sections, so unwinds
through the 32 bit libc.so don't work. It will be supported very soon,
but even then, it will be slower to use, so make sure the debug_frame
is not compressed at all.
Bug: 309857311
Test: 32 bit debuggerd unit tests pass.
Test: 32 bit unwind unit tests pass.
Change-Id: Ic8bec1d275c629ec43051bbe912014f281450eda
Investigation revealed that the vector instructions in the assembly
implementation of memcmp seem to be putting QEMU into a bad state. This
code sometimes results in a SIGILL.
Temporarily disable the vector instructions for just this function.
Bug: 306514350
Test: Verified boot on AOSP CF image.
Change-Id: I184762354092b4b500c78a29a10db18cef0dab90
Rather than do the work to fix the ODR violations while preserving non-V,
let's just remove the non-V code. Android will require V anyway, and
anyone trying to work on a non-V system in the meantime already needs
a bunch of patches to the build system and ART, so one more shouldn't
hurt too much.
Test: treehugger
Change-Id: Iab43d8a80d99a4d045b0008dbea4e7e8696d1167
As part of the build, soong runs the following cmd
```
$ versioner -o <out_dir> bionic/libc/include
bionic/libc/versioner-dependencies
```
To migrate this action to Bazel, create a filegroup module for
`bionic/libc/versioner-dependencies`. In Bazel builds, this target will
be copied to the Bazel's sandbox and placed on the include path when
running versioner. This should be a no-op in Soong.
`bionic/libc/versioner-dependencies` is a collection of symlinks, some of
which point to `prebuilts/clang-tools`. Bazel supports incremental
builds with symlinks out-of-the-box, so we do not need to add special
handling for this directory.
Bug: 301169067
Test: m nothing
Change-Id: I7cbb92e2248c194038a5690c81fed945dee61ccc
A clang update enabled -Wreorder-init-list by default. Since it doesn't
provide any benefit to the bionic code, disable the warning.
Test: Builds without warnings.
Change-Id: I5891527ef532b59dc2a02b39a5896112411d21f5
Currently, we use sentinels (starting with -1 and ending with 0) in
preinit_array/init_array/fini_array in executables. But after using LTO,
the sentinels can be reordered by LLD and no longer work. So make below
changes to not rely on them:
1. In crtbegin.c, use symbols (like __init_array_start) inserted by the
linker.
2. Add array_count fields in structors_array_t.
3. In static libc, use array_count fields to decide array lengths.
4. To make new dynamic executables work with old libc.so, create a fake
fini_array with sentinels, and pass it to __libc_init. The fake
fini_array contains a function to call functions in real fini_array.
5. To make old dynamic executables work with new libc.so, libc.so
still uses sentinels to decide the length of fini_array.
Bug: 295944813
Bug: https://github.com/android/ndk/issues/1461
Test: run bionic-unit-tests-static
Test: test static executables manually
Test: boot cf_gwear_x86-trunk_staging-userdebug
Change-Id: I1ce31f07bcfe0e99b4237984898a8fc9e98ff426
Those flags were used to suppress ABI tidy errors, but by now are not in
use anymore and can safely be removed.
Bug: 156513478
Change-Id: Ibc9625d139f933e48ebb4ddebe70d424f6231f3f
Signed-off-by: Matthias Maennich <maennich@google.com>
These are the same function for machines with binary floats (that is:
all machines), but ldexp() is in libc rather than libm, so we can't just
use an alias.
We were using this duplicate copy of the code, but upstream FreeBSD has
removed it, and I'd prefer to do the same.
Longer term, we should just move all of libm into libc (but keep an
empty libm for compatibility), but this is probably easier for now.
Test: treehugger
Change-Id: I1a1d6d4f1771316f791ad59c714a3a65aedefc81
This works (by reading /etc/localtime) on NetBSD, but not on Android
since we have no such file. Fix that by using our equivalent system
property instead.
Also s/time zone/timezone/ in documentation and comments. We've always
been inconsistent about this (as is upstream in code comments and
documentation) but it seems especially odd now we expose a _type_ that
spells it "timezone" to talk of "time zone" even as we're describing
that type and its associated functions.
Bug: https://github.com/chronotope/chrono/issues/499
Test: treehugger
Change-Id: I142995a3ab4deff1073a0aa9e63ce8eac850b93d
* Rationale
The question often comes up of how to use multiple time zones in C code.
If you're single-threaded, you can just use setenv() to manipulate $TZ.
toybox does this, for example. But that's not thread-safe in two
distinct ways: firstly, getenv() is not thread-safe with respect to
modifications to the environment (and between the way putenv() is
specified and the existence of environ, it's not obvious how to fully
fix that), and secondly the _caller_ needs to ensure that no other
threads are using tzset() or any function that behaves "as if" tzset()
was called (which is neither easy to determine nor easy to ensure).
This isn't a bigger problem because most of the time the right answer
is to stop pretending that libc is at all suitable for any i18n, and
switch to icu4c instead. (The NDK icu4c headers do not include ucal_*,
so this is not a realistic option for most applications.)
But what if you're somewhere in between? Like the rust chrono library,
for example? What then?
Currently their "least worst" option is to reinvent the entire wheel and
read our tzdata files. Which isn't a great solution for anyone, for
obvious maintainability reasons.
So it's probably time we broke the catch-22 here and joined NetBSD in
offering a less broken API than standard C has for the last 40 years.
Sure, any would-be caller will have to have a separate "is this
Android?" and even "is this API level >= 35?" path, but that will fix
itself sometime in the 2030s when developers can just assume "yes, it
is", whereas if we keep putting off exposing anything, this problem
never gets solved.
(No-one's bothered to try to implement the std::chrono::time_zone
functionality in libc++ yet, but they'll face a similar problem if/when
they do.)
* Implementation
The good news is that tzcode already implements these functions, so
there's relatively little here.
I've chosen not to expose `struct state` because `struct __timezone_t`
makes for clearer error messages, given that compiler diagnostics will
show the underlying type name (`struct __timezone_t*`) rather than the
typedef name (`timezone_t`) that's used in calling code.
I've moved us over to FreeBSD's wcsftime() rather than keep the OpenBSD
one building --- I've long wanted to only have one implementation here,
and FreeBSD is already doing the "convert back and forth, calling the
non-wide function in the middle" dance that I'd hoped to get round to
doing myself someday. This should mean that our strftime() and
wcsftime() behaviors can't easily diverge in future, plus macOS/iOS are
mostly FreeBSD, so any bugs will likely be interoperable with the other
major mobile operating system, so there's something nice for everyone
there!
The FreeBSD wcsftime() implementation includes a wcsftime_l()
implementation, so that's one stub we can remove. The flip side of that
is that it uses mbsrtowcs_l() and wcsrtombs_l() which we didn't
previously have. So expose those as aliases of mbsrtowcs() and
wcsrtombs().
Bug: https://github.com/chronotope/chrono/issues/499
Test: treehugger
Change-Id: Iee1b9d763ead15eef3d2c33666b3403b68940c3c
Add vector version mem* and str* functions and only build them when the
vector extension is enabled.
The original implementation comes from
https://github.com/sifive/sifive-libc, which we agree to contribute to
the Android Open Source Project.
Test: mma
Change-Id: I11b671a5bc571d7c783a657f272f282df7d16c29
Signed-off-by: Yun Hsiang <yun.hsiang@sifive.com>
Nothing to see here --- you'll want to keep using POSIX clock_gettime()
and clock_getres() instead. But portable code might use this eventually,
and it's trivial, so let's add it anyway.
(The whole "zero as an error return" precluding the direct use of
Linux's CLOCK_ constants is what really makes this a terrible API ---
we're going to have to add explicit translation any time they add a
new base.)
Test: treehugger
Change-Id: Iddb6cbe67b67b2b10fdd8b5ee654896d23deee47
This reverts commit fe2907c133.
Reason for revert: Breaks bionic-unit-tests b/278795547. Since the original mixed build change is being reverted for now (aosp/2547450), fe2907c133 is not needed immediately
Change-Id: I2deb06a38322bf8296d4721c840f06f35b757177
bp2build will generate the stub targets only if versions is not empty.
Test: b query //bionic/libc:* | grep libc_hwasan_stub_libs-current
Change-Id: Iac905497ae4955a44b7b29e2d29a2c702c86da8e
