The libtest_empty.so was built by the "libtest_empty" build rule, and
the other files are copies of that with small edits made by the toybox
hexedit tool. I worked out what to edit in each case from a combination
of "what does the name imply?" and "what does a diff of the xxd output
of the corresponding two arm64 files show?".
I failed to produce a working (by which I mean "failing") local-tls
file despite my best efforts. I'm not sure what exactly it was about the
gold-generated files we didn't like, because the commentary implies that
this would be problematic:
39: 0000000000000004 4 TLS LOCAL DEFAULT 12 tls_var_2
But it loads without complaint.
Test: ran locally
Change-Id: I3b9b2b4db1f8827243541cf13380c6ceb840f123
We'll want to come back to this once either Zcmp's push/pop instructions
or V's vector loads/stores are available. But for now, we have no >64b
stores.
But at least this builds.
Test: treehugger
Change-Id: I9503e890cacb198f4ba987bfc92f6eff21c290b0
This commit disables MemtagNoteTest#SEGV when running
on native bridge.
Bug: http://b/242170715
Test: run arm64 Bionic tests on T Emulator
Change-Id: I8ae99c5ba22f09a8d7e751f8bb4938894abe231f
The PRNG seeder daemon is introduced in TM-QPR2 which can lead to
breakage running Android 13 CTS tests depending on when the platform
and CTS tests are built.
Fix: 253185870
Test: run cts --module CtsBionicTestCases
Change-Id: I94fa0aa2f32b09222aee08891e7643bf14d1a204
riscv64 hates nans. From the spec: "Except when otherwise stated, if the
result of a floating-point operation is NaN, it is the canonical NaN.
The canonical NaN has a positive sign and all significand bits clear
except the MSB, a.k.a. the quiet bit."
This broke our tests here because the float-to-double instruction isn't
one of the "otherwise stated" cases, so it turns -nanf() into +nan().
The sign manipulation instructions are "otherwise stated" cases, though,
so as long as we avoid a conversion we're fine. And we didn't actually
_need_ a float here (pretty much by definition, since varargs means you
always end up with a double anyway), so we can just simplify things and
switch to using doubles directly to fix the tests.
Test: bionic-unit-tests-static
Change-Id: I13aa452dd6cc8708275f7676b37fc772b37a7b32
This is mainly just to match what we have for arm64.
The test failures before and after this change are all for the long
double variant, which this change doesn't touch. (The problem there is
that clang is calling `__fixtfdi` for the cast in lrintl(), but that
doesn't respect the current rounding mode, which lrintl() is required
to do. `#pragma STDC FENV_ACCESS ON` doesn't fix this, so there's going
to be some llvm work needed to fix this.)
I've replaced the ASSERTs with EXPECTs in the relevant test to ensure
we're checking all the other assertions despite the `long double`
failures.
Test: bionic-unit-tests-static
Change-Id: Ia24bf21619631b6f8b3b607d30536011bb4cd826
Musl doesn't export __SIGRTMIN, and it is being removed from the
Android wrappers to avoid accidentally referencing bionic's
reserved signals when compiling against musl.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native -k
Change-Id: I342666a17abc31bbc57b383b5cc881c2752886f7
Group riscv64 with arm/arm64, and allow for the fact that there's no
FE_DENORMAL in the riscv64 spec.
Test: fenv.*
Change-Id: Ibf188bcedffd092a7ef1555fa2762e249e1f9845
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: m
Change-Id: I02cf117f67bda74516e4de8cd6f4c05efdb9a85b
I haven't found this explicitly stated anywhere, but it's how our
existing implementations behave, and it seems obviously implied by
the word "entire" in POSIX's claim that fenv_t "Represents the entire
floating-point environment".
Test: treehugger
Change-Id: Ic8fc993775b4ded57dc88766a7d24d0954f3b56d
(And all other new architectures.)
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: treehugger
Change-Id: Iceb2dd16c738302624980179788c4a2e68b797ed
I've never been able to repro the flake myself (in hundreds of thousands
of runs), but it's certainly possible that a byte of the cookie is
already zero. So let's invert the byte we plan to corrupt rather than
set it to zero.
Bug: http://b/202948861
Test: treehugger
Change-Id: Iccd552fe302d6c01e376819d23c11a308e03acdb
(cherry picked from commit 23ce50c172)
Upstream musl libc defines sysinfo.uptime as unsigned long, while the
kernel and glibc define it as long. Cast it to long for the
comparision.
Bug: 190084016
Test: bionic-unit-tests-glibc
Change-Id: Ib322472d512a9a7474a936e33f35523e1dc995d9
I've never been able to repro the flake myself (in hundreds of thousands
of runs), but it's certainly possible that a byte of the cookie is
already zero. So let's invert the byte we plan to corrupt rather than
set it to zero.
Bug: http://b/202948861
Test: treehugger
Change-Id: Iccd552fe302d6c01e376819d23c11a308e03acdb
At the time I added <stdio_ext.h>, I just added what was on the man
page (which matched glibc), not realizing that musl and glibc had
slightly different functionality in their headers.
The toybox maintainer came up with a legitimate use case for this, for
which there is no portable workaround, so I'm adding it here. I'm not
adding the other functions that are in musl but not glibc for lack of a
motivating use case.
Bug: http://lists.landley.net/htdig.cgi/toybox-landley.net/2022-April/020864.html
Test: treehugger
Change-Id: I073baa86ff0271064d4e2f20a584d38787ead6b0
This tests cover stack tagging setup in response to NT_MEMTAG_STACK and
vfork and longjmp support.
Bug: b/174878242
Test: fvp_mini with ToT LLVM
SANITIZE_TARGET="memtag_heap"
SANITIZE_TARGET="memtag_heap,memtag_stack"
Change-Id: I7fee03d901092d9428d86a6fab6bef4e2e3b51eb
Coming to C23 via WG14 N2630.
This one is a little interesting, because it actually changes existing
behavior. Previously "0b101" would be parsed as "0", "b", "101" by these
functions. I'm led to believe that glibc plans to actually have separate
versions of these functions for C23 and pre-C23, so callers can have the
behavior they (implicitly) specify by virtue of which -std= they compile
with. Android has never really done anything like that, and I'm pretty
sure app developers have more than enough to worry about with API levels
without having to deal with the cartesian product of API level and C
standard.
Therefore, my plan A is "if you're running on Android >= U, you get C23
behavior". My plan B in the (I think unlikely) event that that actually
causes trouble for anyone is "if you're _targeting_ Android >= U, you
get C23 behavior". I don't think we'd actually want to have two versions
of each of these functions under any circumstances --- that seems by far
the most confusing option.
Test: treehugger
Change-Id: I0bbb30315d3fabd306905ad1484361f5d8745935
Coming to C23 via WG14 N2630, and already in glibc.
We're still missing clang support for %b and %B in format string checking,
but it's probably easier to fix this first. (Apparently GCC already has
support because of glibc.)
Test: treehugger
Change-Id: Ie8bfe4630d00c50e1d047d6756a7f799205356db
