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
This mode instructs the linker to search for libraries in hwasan
subdirectories of all library search paths. This is set up to contain a
hwasan-enabled copy of libc, which is needed for HWASan programs to
operate. There are two ways this mode can be enabled:
* for native binaries, by using the linker_hwasan64 symlink as its
interpreter
* for apps: by setting the LD_HWASAN environment variable in wrap.sh
Bug: 276930343
Change-Id: I0f4117a50091616f26947fbe37a28ee573b97ad0
Bazel doesn't like it when modules produce files with the same name
as the module itself, and gives warnings.
Rename either the module or file in this case so that the file has
an extension and the module doesn't.
Bug: 198619163
Test: m nothing
Change-Id: Ic4592b06f575496ffd54ac75cb4d682118b29d93
Use __memcpy_chk assembly to replace the implementation of c functions, which can reduce the use of instructions
Test: llvm-objdump
Change-Id: I5d75601626dc997626f6173d53af301183a64004
Signed-off-by: caowencheng <caowencheng@eswincomputing.com>
clang-r487747 added stack protector capability to check noreturn calls.
This caused the system to boot loop. Turn off the new capabilities as a
temporary workaround.
Test: build and boot
Change-Id: I62c912619dfdd2384672d504ce5d52330bf2a102
Writing an assembly file can reduce several
assembly instructions, and compare it through
the disassembly of this file
Test: make libc
Change-Id: Ifdcc9c76742cc95b2ad9e3c14fac4796c36e12e6
Signed-off-by: caowencheng <caowencheng@eswincomputing.com>
These are just one-liners, and the _FLOCK() macro seemed to me more
obscure than just inlining it (especially because there are only four
call sites total, so it's not like anyone's going to see that macro very
often).
Also add the missing CHECK_FP() calls. I don't expect this to break
anything, but if it does we can add a target API level check.
Test: treehugger
Change-Id: Ifa1a39d5d9eee46cca783acbe9ec3b3a1e6283d9
Get bsearch and other baremetal-compatible functions from NetBSD.
Bug: 249723852
Bug: 262344886
Test: -
Change-Id: Idd90188ae13c84ed35af8f1475370cec0fe8cdbb
GWP-ASan's recoverable mode was landed upstream in
https://reviews.llvm.org/D140173.
This mode allows for a use-after-free or a buffer-overflow bug to be
detected by GWP-ASan, a crash report dumped, but then GWP-ASan (through
the preCrashReport() and postCrashReportRecoverableOnly() hooks) will
patch up the memory so that the process can continue, in spite of the
memory safety bug.
This is desirable, as it allows us to consider migrating non-system apps
from opt-in GWP-ASan to opt-out GWP-ASan. The major concern was "if we
make it opt-out, then bad apps will start crashing". If we don't crash,
problem solved :). Obviously, we'll need to do this with an amount of
process sampling to mitigate against the 70KiB memory overhead.
The biggest problem is that the debuggerd signal handler isn't the first
signal handler for apps, it's the sigchain handler inside of libart.
Clearly, the sigchain handler needs to ask us whether the crash is
GWP-ASan's fault, and if so, please patch up the allocator. Because of
linker namespace restrictions, libart can't directly ask the linker
(which is where debuggerd lies), so we provide a proxy function in libc.
Test: Build the platform, run sanitizer-status and various test apps
with recoverable gwp-asan. Assert that it doesn't crash, and we get a
debuggerd report.
Bug: 247012630
Change-Id: I86d5e27a9ca5531c8942e62647fd377c3cd36dfd
Add strtol (required by libfdt), which only depends on libc functions
the library already provides or requires.
Bug: 232900974
Test: m pvmfw_bin # with aosp/2314779
Change-Id: I460571b64369c6bf45fef213252f305e978c694d
Add __memcpy_chk (used by BoringSSL) and start documenting the
dependencies that the baremetal environment needs to provide to
successfully link the library.
Bug: 256148034
Bug: 256827715
Test: m pvmfw_bin && atest vmbase_example.integration_test
Change-Id: I0d61f4efc5cc26a95b74870be7cd7eebeeb0bd3a
LLVM/rustc compiling no_std code expects a few libc symbols to be
defined (memcpy, memset, memcmp). Previously, we used the arm64 library
directly; instead, make the dependency arch-agnostic by exporting it
from Bionic, making it easier to add more libc functions (that might not
be implemented by the optimized routines), as necessary.
Test: m pvmfw_bin && atest vmbase_example.integration_test
Change-Id: I1d2cc69a25bbb7eddc67357a028b7b79d4909e79
We still have local differences, but this minimizes (and documents) them.
Bug: http://b/167569813
Test: treehugger
Change-Id: Ib90e6ccc5ec1224e7ee89224a51b87fc48c9931f
This one's a bit simpler, because there is only one upstream memset()
implementation.
Test: treehugger
Change-Id: I2536d0eb72adaacfa6a0e40d2bd29fc833988c16
Outsource this to them, and choose the best of the two options available
based on the hardware we're running on.
Test: treehugger
Change-Id: I2fa7555c971b64a6decca132210e901ffa248efa
These two will stay behind when we move memcpy()/memmove()/memset() over
to arm-optimized-routines (which leaves fortify to us).
Test: treehugger
Change-Id: Ie683f71a5a141263ce3f4e8811df9eaf667584f4
The compiler turns our C wmemmove() into one shift instruction and a
branch, which is plenty for a function no-one uses anyway.
Why don't I just leave this alone, since we already have it? Because I'm
looking at finishing the project of "switch to arm-optimized-routines"
and getting rid of our assembler here, and Arm agrees that this isn't
worth having optimized assembler for in their optimized assembler
project, judging by its absence.
Test: treehugger
Change-Id: I985801241a8cbd7dbda51a447946affb1402effb
The ndk sysroot does not include the crt*.o objects, package them
separately for use in the llvm toolchain build.
Test: lunch aosp_riscv64-userdebug && m bionic_sysroot_crt_objects
Change-Id: I0bda12b7979a026441bb67387709ee94b3249b6b
Add riscv64 kernel headers to the ndk sysroot for use by the LLVM
toolchain build. They will not be shipped in the real NDK.
Test: lunch aosp_riscv64-userdebug && m ndk_sysroot
Change-Id: I804e66b56919b84fa5dc03d432ae673ea4f31615
