Implement accept4 on x86 android with `socketcall` syscall.
Linux x86 kernels before 4.3 only support the `socketcall` syscall rather than individual syscalls for socket operations. Since `libc` does a raw syscall for `accept4` on Android, it doesn't work on x86 systems.
This PR instead implements `accept4` for x86 android using `socketcall`. The value for `SYS_ACCEPT4` (in contrast to `SYS_accept4` 👀) is taken from the `linux/net.h` header.
Also note that the `socketcall` syscall takes all arguments as array of long ints. I've double checked with `glibc` to check how they pass arguments, since the Linux man page only says this: "args points to a block containing the actual arguments" and "only standard library implementors and kernel hackers need to know about socketcall()".
This should fix https://github.com/rust-lang/rust/issues/82400
Linux x86 kernels before 4.3 only support the `socketcall` syscall rather than individual syscalls for socket operations. Since `libc` does a raw syscall for `accept4` on Android, it doesn't work on x86 systems.
This PR instead implements `accept4` for x86 android using `socketcall`. The value for `SYS_ACCEPT4` (in contrast to `SYS_accept4` 👀) is taken from the `linux/net.h` header.
Also note that the `socketcall` syscall takes all arguments as array of long ints. I've double checked with `glibc` to check how they pass arguments, since the Linux man page only says this: "args points to a block containing the actual arguments" and "only standard library implementors and kernel hackers need to know about socketcall()".
This should fix https://github.com/rust-lang/rust/issues/82400
Fix mips64-musl ioctl consts to c_int
This arch was overlooked or unspecified in earlier PRs that fixed
c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301,
or PR #1097 for such prior art, however these are still args to
fn ioctl on mips64-musl, which is expecting c_ints.
Some numbers acquired casts to reflect the fact the data is being
used and (so should be written as) an unsized bitfield, even if
the value is greater than i32::MAX.
Currently rustc is not building on mips64-linux-musl because of this error.
This arch was overlooked or unspecified in earlier PRs that fixed
c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301,
or PR #1097 for such prior art, however these are still args to
fn ioctl on mips64-musl, which is expecting c_ints.
Some numbers acquired casts to reflect the fact the data is being
used and (so should be written as) an unsized bitfield, even if
the value is greater than i32::MAX.
WASI: define `AT_FDCWD` and update to latest WASI libc
Update to the latest WASI libc, define `AT_FDCWD`, update the signature
for __wasilibc_find_relpath, and add declarations for various
`__wasilibc_` utility functions.
Update to the latest WASI libc, define `AT_FDCWD`, update the signature
for __wasilibc_find_relpath, and add declarations for various
`__wasilibc_` utility functions.
Haiku: use raw pointers instead of references in convenience functions
The Haiku API has some convenience macros to make it easier to call certain
functions. In the libc implementation, these are implemented as unsafe
functions. The previous choice was to take certain pointer parameters as
references, and do the conversion to raw pointers when the actual external
function was called.
However, this causes issues with the image_info struct, which needs to be
initialized in Rust, before a native API call is used to enter data. Since
part of this structure consists of function pointers, mem::zeroed() cannot be
used, since in Rust function pointers cannot be NULL. Thus one needs to use the
MaybeUnit<T> API to properly initialize it. This then makes it problematic to
use the convenience functions, as a MaybeUnit<image_info> cannot be converted
into an &mut image_info before it is marked as initialized with valid data. It can
be converted into a raw *mut image_info, so if the function accepts this as a
parameter it can be used.
For consistency, all convenience functions have been converted from using
references to using raw pointers.
Move uclibc under linux
This is a first cut at moving uclibc under linux, alongside `musl` and `gnu`.
All tests pass on a vexpress a9 running in qemu. I am working on testing the other tier 3 uclibc targets: `mips-unknown-linux-uclibc` and `mipsel-unknown-linux-uclibc`. ~Not having access to these platforms, I am working on getting them running in qemu, but it may take a bit.~
The style check doesn't pass. I would appreciate some direction here. Many of these constants are defined under 2-of-3 out of musl/glibc/uclibc, so I'm not sure whether I should transform:
```rust
#[cfg(not(target_env = "uclibc"))]
pub fn foo();
```
into 2 separate declarations, one each in `musl/mod.rs` and `gnu/mod.rs` or use a `cfg_if` block for each one (which explodes 2 lines into 5).
- [x] Help me choose which fix to use for the items defined in musl and gnu but not uclibc.
It's my guess that exploding into the `cfg_if` block is better for long-term maintainability, but I'd really appreciate opinions from the maintainers.
The Haiku API has some convenience macros to make it easier to call certain
functions. In the libc implementation, these are implemented as unsafe
functions. The previous choice was to take certain pointer parameters as
references, and do the conversion to raw pointers when the actual external
function was called.
However, this causes issues with the image_info struct, which needs to be
initialized in Rust, before a native API call is used to enter data. Since
part of this structure consists of function pointers, mem::zeroed() cannot be
used, since in Rust function pointers cannot be NULL. Thus one needs to use the
MaybeUnit<T> API to properly initialize it. This then makes it problematic to
use the convenience functions, as a MaybeUnit<image_info> cannot be converted
into an &image_info before it is marked as initialized with valid data. It can
be converted into a raw *mut image_info, so if the function accepts this as a
parameter it can be used.
For consistency, all convenience functions have been converted from using
references to using raw pointers.
Remove unused iconv.h includes
These are left over from 3e4d684dcd, which
added includes to *all* platforms despite adding bindings only to *some*
of them. This already broke OpenBSD which doesn't have iconv.h (fixed by
915d8fac81), and is just distasteful, so
down with those unused includes.
(This is a continuation to #2037 and #2067.)
Linux: Add `preadv2` and `pwritev2` and associated constants
These functions are the same as `preadv` and `pwritev` but have a flags
parameter. `preadv2()` and `pwritev2()` first appeared in Linux 4.6.
Library support was added in glibc 2.26.
See the definition of the constants in [linux/fs.h](fcadab7404/tools/include/uapi/linux/fs.h (L288-L301)).
Add mount ID to statx
This mirrors the modifications to `include/uapi/linux/stat.h` by [Linux commit fa2fcf4f1df1559a0a4ee0f46915b496cc2ebf60 (“statx: add mount ID”)](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fa2fcf4f1df1559a0a4ee0f46915b496cc2ebf60).
What changed in v2 (v1: #2023):
* Skip testing the new `STATX_MNT_ID` constant, because it’s only part of Linux as of 5.8. That’s too new e.g. for Ubuntu 20.04.1 (with a kernel derived from 5.4), which is what’s used by the CI.
From `linux/mod.rs`. These constants are not exposed by musl so were
causing failures in CI.
These constants are really defined in `include/uapi/linux/fs.h` in Linux
and are not specific to any libc and I hope to make them more available in
the future.
These are left over from 3e4d684dcd, which
added includes to *all* platforms despite adding bindings only to *some*
of them. This already broke OpenBSD which doesn't have iconv.h (fixed by
915d8fac81), and is just distasteful, so
down with those unused includes.
This corresponds to the Linux commit
fa2fcf4f1df1559a0a4ee0f46915b496cc2ebf60 ("statx: add mount ID").
Note that STATX_ALL is not modified to include this field, because it
has actually been deprecated in Linux and is now effectively defined as
equal to STATX_BASIC_STATS | STATX_BTIME (see Linux commit
581701b7efd60ba13d8a7eed60cbdd7fefaf6696, "uapi: deprecate STATX_ALL").
Because said commit fa2fcf4f1d is less than a year old, skip testing the
STATX_MNT_ID constant.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Padding and reserved fields should not be publicly accessible, because
they may be replaced by new (functional) fields at any time.
Searching for these padding fields on github or Google reveals no users,
so making them private should not break any existing users.
It is possible that there are projects outside of github that access
these fields, but if so, they should have been warned by the fact that
these fields are prefixed by double underscores.
Signed-off-by: Max Reitz <mreitz@redhat.com>
These functions are the same as `preadv` and `pwritev` but have a flags
parameter. `preadv2()` and `pwritev2()` first appeared in Linux 4.6.
Library support was added in glibc 2.26.
Re-enable CI for `asmjs-unknown-emscripten`
#1591 was closed by #1697 but it was only for `wasm32-unknown-emscripten` actually. We should make a new issue and link to it instead if it's still broken.
r? `@ghost`
Ariadne Conill
Lucy Phipps
bors
Jason King
Jubilee Young
James Lee
Dan Gohman
Sean Klein
Jonah Petri
Niels Sascha Reedijk
William Manley
Alexander Batischev
Max Reitz
Sébastien Marie
William Manley
Yuki Okushi