The -1 from pathconf()/fpathconf() with these isn't the "I don't know
what you're talking about" -1/EINVAL, but the "I understand the
question, but don't have an answer for you --- you'll have to try it and
see" -1.
Bug: http://b/326245682
Test: treehugger
Change-Id: I67be277f3ffd9b5a355787ae7ffc4a31e32b0128
The previous implementation wasn't wrong (it returned the "maximum
maximum"), but we can return the actual runtime value from the kernel.
Noticed while looking at initgroups().
Test: treehugger
Change-Id: I891fe4ff29bd82ee05d9e05ed8299d32c21abd7f
The sysconf_SC_ARG_MAX test was failing because it didn't
handle the case for 16k. After fixing the test case, it will
handle 4k/16k page sizes and fail when there is another page
size.
Bug: 315174209
Test: atest -c bionic-unit-tests-static
Change-Id: Ie24a79be9d6790a1243be48d39f67acda485c37d
The close_range() test in particular has been confusing a lot of
partners. I think the sys_epoll_test.cpp idiom is the clearest of the
ones in use, so let's use that everywhere. (I haven't actually touched
the SysV IPC tests, because if we do touch them, _deleting_ them --
since all those syscalls are not allowed on Android -- is probably the
change to be made!)
I'm on the fence about factoring this idiom out into a macro. There
should never be too many of these, and we should probably be removing
them? Is anyone still running the current bionic tests on 4.3 kernels
without membarrier(2), and if they are --- why?!
For now though, I haven't removed any of our existing tests; I've just
moved them over to the sys_epoll_test.cpp style.
Test: treehugger
Change-Id: Ie69a0bb8f416c79957188e187610ff8a3c4d1e8f
We've talked about this many times in the past, but partners struggle to
understand "expected 38, got 22" in these contexts, and I always have to
go and check the header files just to be sure I'm sure.
I actually think the glibc geterrorname_np() function (which would
return "ENOSYS" rather than "Function not implemented") would be more
helpful, but I'll have to go and implement that first, and then come
back.
Being forced to go through all our errno assertions did also make me
want to use a more consistent style for our ENOSYS assertions in
particular --- there's a particularly readable idiom, and I'll also come
back and move more of those checks to the most readable idiom.
I've added a few missing `errno = 0`s before tests, and removed a few
stray `errno = 0`s from tests that don't actually make assertions about
errno, since I had to look at every single reference to errno anyway.
Test: treehugger
Change-Id: Iba7c56f2adc30288c3e00ade106635e515e88179
Musl doesn't have the _SC_LEVEL?_?CACHE_SIZE sysconf macros.
Bug: 257334542
Test: m USE_HOST_MUSL=true host-native
Change-Id: I42e65daa9169e129059ddde5eee487ea51e6f143
This is a bit disappointing. I'd not implemented this in the past
because it wasn't available on all platforms, and -- although the
riscv64 implementation was just a cool optimization -- I thought that
the /sys stuff was actually portable, until I ran it on arm64 hardware.
So here we have getauxval() for riscv64, /sys for x86-64, and our best
guess based on ctr_el0 for arm64.
Bug: http://b/294034962
Test: ran tests on the host, an arm64 device, and riscv64 host and qemu
Change-Id: I420b69b976d30668d4d2ac548c4229e2a4eafb20
We don't support running threads on a tagged stack. Untagging SP may
lead to accesses to the stack via a non-SP register, which will be tag
checked, and the check will fail. And indeed that's exactly what the
__bionic_clone function does in its first instruction. Fix the problem by
disabling HWASan and MTE stack tagging on CloneStartRoutine, and remove
the call to untag_address, as it is unnecessary.
Bug: 273807460
Change-Id: I94cc56c816897531c0113c856b54ec41b4aab874
It came up on the musl mailing list that there's not actually any need
to iterate over the directory entries:
https://www.openwall.com/lists/musl/2022/07/27/1
This lets us reuse the code for "online" processors in the
implementation of "configured" processors. The question of whether
"configured" should correspond to Linux's "possible" or "present" isn't
obvious to me, but the distinction seems unlikely to matter on mobile
devices anyway, and that's a trivial change should it ever be needed.
Plus the motivating argument from the person who brought this up was
that callers asking for "configured" processors are probably asking for
an upper bound, which sounds convincing to me.
Test: treehugger
Change-Id: I0d4e13538dc6b09a6dba520d9ac24f436906f7c0
Musl doesn't have close_range, skip the test.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I7ed485f2d0ec08358c856430b7c4c45fbe45a39f
See:
https://man7.org/linux/man-pages/man2/close_range.2.html
Note: 'man close_range' documents 'flags' as unsigned int,
while glibc unistd.h as just 'int'. Picking 'int' to match glibc,
though it probably doesn't matter.
BYPASS_INCLUSIVE_LANGUAGE_REASON=man is a cli command
Test: TreeHugger
Bug: 229913920
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1e2d1c8edc2ea28922d60f3ce3e534a784622cd1
There are other options here (see the code comment for details), but
this is the least effort/least disruptive for now.
Bug: http://b/227498625
Test: treehugger
Change-Id: I33be6fbfc022238de2f1846a69af1e712a9d6391
clang is smart enough to notice a variable is set but not used,
but these variable are used for testing purposes. Mark one as
unused, and convert the other to a DoNotOptimize.
Bug: 197240255
Test: Compiles without warnings.
Test: Ran unit tests on coral hwasan build.
Change-Id: Ibc873e477355a702579e5a680780c77db0c58046
Modify bionic unit tests that are built for glibc so that they also
build against musl. They don't all pass though:
With glibc:
2 SLOW TESTS
4 TIMEOUT TESTS
313 FAILED TESTS
YOU HAVE 2 DISABLED TESTS
With musl:
11 SLOW TESTS
11 TIMEOUT TESTS
363 FAILED TESTS
YOU HAVE 2 DISABLED TESTS
Bug: 190084016
Test: m bionic-unit-tests-glibc with musl
Test: atest bionic-unit-tests-static
Test: atest --host bionic-unit-tests-glibc with glibc
Change-Id: I79b6eab04fed3cc4392450df5eef2579412edfe1
This has been in the standard since C99, but we've never supported it
before. It's apparently used by SPIRV-Tools.
I tried implementing this the other way (with fcntl(2)) first, but
eventually realized that that's more complicated and gives worse
results. This implementation assumes that /proc is mounted, but so much
of libc relies on that at this point that I don't think there's any
realistic case where the fcntl(2) implementation would be preferable,
and there are many where it's not.
The fact that no-one's mentioned this until now suggests that it's not a
heavily used feature anyway.
I've also replaced AssertCloseOnExec() with a CloseOnExec()
boolean-valued function instead, because it's really annoying getting
assertion failures that don't point you at the test line in question,
and instead point to some common helper code.
Test: treehugger
Change-Id: Ia2e53bf2664a4f782581042054ecd492830e2aed
Bug: http://b/157081822
- Disable coverage for libtest_check_rtld_next_from_library to make
dlfcn.rtld_next_from_library to pass.
- The coverage runtime sets an environment variable to prevent
clobbering of the coverage data on disk. Include that variable as well
when checking `printenv` output. This is done at runtime by checking
for LLVM_PROFILE_FILE environment variable.
- dl.preinit_system_calls still fails after this change.
Test: bionic tests with libc coverage turned on.
Change-Id: I3ea2b0800886d8c0984969a4ee8bfb0da03c33b0
Our various fd debugging facilities get extremely confused by a vforked
process closing file descriptors in preparation to exec: fdsan can
abort, and fdtrack will delete backtraces for any file descriptors that
get closed. Keep track of whether we're in a vforked child in order to
be able to detect this.
Bug: http://b/153926671
Test: 32/64-bit bionic-unit-tests on blueline, x86_64 emulator
Change-Id: I8a082fd06bfdfef0e2a88dbce350b6f667f7df9f
For reasons explained in the code comment, go back to roughly our old
code. The "new" tests are just the old tests resurrected.
This also passes the current toybox xargs tests, which were the
motivation for going back on our earlier decision.
Test: bionic and toybox tests
Change-Id: I33cbcc04107efe81fdbc8166dc9ae844e471173e
Upstream keeps rearranging the deckchairs for these, so let's just
switch to the [roughly] one-liners rather than track that...
Test: treehugger
Change-Id: If655cf7a7f316657de44d41fadd43a8c55ee6f23
Call a hwasan hook in the parent return path for vfork() to let hwasan
update its shadow. See https://github.com/google/sanitizers/issues/925
for more details.
Bug: 112438058
Test: bionic-unit-tests
Change-Id: I9a06800962913e822bd66e072012d0a2c5be453d
The tests were patched earlier to run with tagging heap allocator.
This change enables hwasan code instrumentation in the tests themselves,
and fixes the issues that arise, mainly in the code that:
* compares addresses of unrelated stack variables
* compares address of a stack variable with stack limits as found in
/proc/self/maps
* writes address of a stack variable to a hardware watchpoint register
etc.
Note that static tests are broken at the moment, like all static
binaries. Dynamic tests pass 100% with this change.
Bug: 114279110, 124007027
Test: SANITIZE_TARGET=hwaddress; run dynamic bionic tests
Change-Id: I68b8df9dd3e30b47734ddc083811a75a7f27deaa
glibc and musl both have these as synonyms for one another, so we may
as well do the same and get backwards compatibility on old OS releases.
Bug: N/A
Test: ran tests
Change-Id: I6bf38ea446560e1b11022ff539f07eb67c157049
The code (and comment) have been like this since the initial commit, but
there was never a test of this, and glibc seems to have been returning
EINVAL (as POSIX says it should) since long before Android existed.
Bug: http://b/31154352
Test: ran tests
Change-Id: Ica1ea836a4a5699ef0d956fe9c0f322e567de34d
We saw crashes from pthread_exit+debuggerd on LP32
(https://issuetracker.google.com/72291624), and it seems like the
equivalent problem should exist with system(3). I fixed posix_spawn(3)
as part of that bug, so the easiest fix is probably to reuse that.
Bug: http://b/72470344
Test: ran tests
Change-Id: I05f838706f2b4a14ac3ee21292833e6c8579b0d4
Based on gaps in the list of functions not referenced by the test
executable.
Bug: N/A
Test: ran tests
Change-Id: I73c238e7cf360f94670c7cd13eb954341c940b7b
A previous change added new assertions about these, but didn't remove
these old now-invalid assertions.
Bug: http://b/68133223
Test: ran tests
Change-Id: Ib6ce6e5f7abe143f2c871e074e7fd51faaf452ac
I'm skeptical about the usefulness of this, but it's in POSIX, it's
in glibc (but not iOS), and it is used in some internal source (test
runners and container code).
Bug: N/A
Test: ran tests
Change-Id: I92c5398f2a679b21a33fba92bc8e67e3ae2eb76f
Surprisingly to me, there are actual uses of `swab` in the codebases
I have available to search, including one with a #ifndef __ANDROID__
around it.
Bug: N/A
Test: ran tests
Change-Id: Ic91b78ae22bb65c346cb46dd38916f48d979abe0
Went through the POSIX spec for the _POSIX* and _XOPEN* constants.
Bug: http://b/32776472
Test: ran tests
Change-Id: I389100dbc7de354eae9056e44b0a7fa8c37374e3
The newest of these clocks was added in Linux 2.6.12, so no need for runtime
checks.
Add CTS tests that we can actually use the various clocks.
Bug: http://b/67458266
Test: ran tests
Change-Id: I3cfd7982043d6f8d4ebdc2b29e8722334f443ce5
Not sure how this managed to cling on in AOSP master, but all the other
mentions of this constant in AOSP master are already expecting the new
value anyway.
Bug: N/A
Test: ran tests
Change-Id: I8b6b4b320eeb1c4cea1c06bea4c1e8e314ee344d
GMM calls this system call directly at the moment. That's silly.
Bug: http://b/36405699
Test: ran tests
Change-Id: I1e14c0e5ce0bc2aa888d884845ac30dc20f13cd5
