add definitions for s390x musl targets
Add support for s390x musl targets to libc.
I haven't added CI because I am not familiar with the pipelines, but would be glad to do so if somebody outlines what needs to be done.
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
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.
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.
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.
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)).
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.
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.
Haiku: add definitions for the Haiku's native sytem API.
On the Haiku platform, the POSIX (and BSD) API coexists with the native API,
that has its origins on the BeOS platform. Unlike other UNIX-like platforms,
the native API is not an extension of the POSIX API, but instead exists sui
generis, and many of the POSIX concepts have their own native variety, with
relatively limited interoperability.
Nonetheless, the native API coexists in the same library as the standard C and
POSIX functions, namely libroot.so, and therefore this crate is a good place
to add bindings to it.
This commit implements most of Haiku's support kit, the most important parts
of the kernel kit, and a part of the storage kit.
On the Haiku platform, the POSIX (and BSD) API coexists with the native API,
that has its origins on the BeOS platform. Unlike other UNIX-like platforms,
the native API is not an extension of the POSIX API, but instead exists sui
generis, and many of the POSIX concepts have their own native variety, with
relatively limited interoperability.
Nontheless, the native API coexists in the same library as the standard C and
POSIX functions, namely libroot.so, and therefore this crate is a good place
to add bindings to it.
This commit implements most of Haiku's support kit, the most important parts
of the kernel kit, and a part of the storage kit.
These are all handled in src/unix/mod.rs now, which also addresses the
crt-static case; no linux-gnu target should have any link directives in
any other module.
This fixes static linking with glibc for various architectures.
Add port_notify struct for illumos and Solaris
This adds a missing struct for configuring event ports notifications. The `libc-test` suite passes on illumos (OmniOSCE) and is assumed to pass on Solaris, given that the interface has been present since Oracle forked from OpenSolaris.
Add timer interface for illumos and Solaris
This adds the `timer_*` family of functions present in illumos (and Solaris), along with the associated types. The `libc-test` suite passes on an illumos (OmniOSCE) machine. While I do not have resources available to test on Solaris, these interfaces have been stable since Oracle forked.
Add preadv and pwritev for macOS
Add declarations for the preadv and pwritev system calls, introduced
in macOS 11.0 (Big Sur).
Signed-off-by: Sergio Lopez <slp@redhat.com>
Fix missing dl lib on armv5te-unknown-linux-uclibceabi
I'm unable to link my executable for the Linux uClibc environment because of some missing symbols from the dl lib:
```
/home/operutka/goodcam/goodcam-server/target/armv5te-unknown-linux-uclibceabi/release/deps/goodcam_server-aefb92c403e8cd55.goodcam_server.dzc3futp-cgu.0.rcgu.o: In function `mio::sys::unix::dlsym::fetch::he5e2964820cfd29d':
goodcam_server.dzc3futp-cgu.0:(.text._ZN3mio3sys4unix5dlsym5fetch17he5e2964820cfd29dE+0x30): undefined reference to `dlsym'
/home/operutka/goodcam/goodcam-server/target/armv5te-unknown-linux-uclibceabi/release/deps/goodcam_server-aefb92c403e8cd55.goodcam_server.dzc3futp-cgu.0.rcgu.o: In function `std::sys::unix::weak::fetch::h5ed4b0fa5792ef5c':
goodcam_server.dzc3futp-cgu.0:(.text._ZN3std3sys4unix4weak5fetch17h5ed4b0fa5792ef5cE+0x3c): undefined reference to `dlsym'
```
The libc crate is being used at both of these points.
This change fixes the issue for me. I've tested it with two different GCC cross toolchains for armv5te and it seems to be OK.
_Note: I'm building my own std using the unstable build-std Cargo feature._
Fix error when building rustc with a custom libc
When pulling a custom `libc` into a `rustc` build (with the `rustc-dep-of-std` feature set), the following error occurs:
```
error: unused attribute
--> /hdd/libc/src/lib.rs:29:1
|
29 | #![no_std]
| ^^^^^^^^^^
|
= note: `-D unused-attributes` implied by `-D warnings`
error: crate-level attribute should be in the root module
--> /hdd/libc/src/lib.rs:29:1
|
29 | #![no_std]
| ^^^^^^^^^^
```
I think this is because both the `no_std` and `no_core` attributes are specified, although the error message doesn't make this very clear. This PR changes this so `no_std` is only supplied when the `rustc-dep-of-std` feature is not.
Add definitions from `linux/can.h`, which is a "base" header for remainder
of SocketCAN functionality.
Signed-off-by: Damian Jarek <damian.jarek93@gmail.com>
Make test suite pass on macOS on aarch64
While working on #2007 I tried to run `cargo test` in `libc-test`, which failed, because the definition of `__darwin_mcontext64` was incomplete (see #1990). This adds definitions for the exception state and the floating point state as well.
`libc-test` still does not pass, because I use the type `[u128; 32]` for the `__v` field of `__darwin_arm_neon_state64` (in C it is `__uint128_t __v[32]`. `ctest2` does not translate `u128` to `__uint128_t` and the generated C code does not compile. Any ideas for working around this?
On FreeBSD, the aio_ functions require librt _only_ if they use
SIGEV_THREAD completion notification. However, due to Rust's originally
poor support for C unions, libc doesn't even expose some of the fields of
struct sigevent that SIGEV_THREAD requires. Accordingly, there is no
need to link librt to programs using aio via libc.
This change partially reverts 8c23f77704
from PR #1630 .
While I'm here, fix the linkage of lio_listio on DragonflyBSD. It
_does_ require librt.
Adds the ip_mreqn struct for the Fuchsia platform, as defined by ip(7).
Enables joining an IPv4 multicast group by NIC ID rather than by its
assigned IPv4 address.
Declare statfs MAGIC constants as c_uint on s390x
Hi, I work in container development on Linux on Z at IBM.
On s390x (IBM Z) in GNU/Linux, a statfs `f_type` is 4 bytes wide, contrary to 8 bytes on most architectures.
This is already implemented in libc:
```sh
$ grep -r f_type src/unix/linux_like/linux/gnu/b64 | uniq
src/unix/linux_like/linux/gnu/b64/sparc64/mod.rs: pub f_type: ::__fsword_t,
src/unix/linux_like/linux/gnu/b64/aarch64/mod.rs: pub f_type: ::__fsword_t,
src/unix/linux_like/linux/gnu/b64/powerpc64/mod.rs: pub f_type: ::__fsword_t,
src/unix/linux_like/linux/gnu/b64/riscv64/mod.rs: pub f_type: ::c_long,
src/unix/linux_like/linux/gnu/b64/mips64/mod.rs: pub f_type: ::c_long,
src/unix/linux_like/linux/gnu/b64/s390x.rs: pub f_type: ::c_uint, # s390x is uint
src/unix/linux_like/linux/gnu/b64/x86_64/mod.rs: pub f_type: ::__fsword_t,
```
However, the `*_MAGIC` constants (such as `EXT4_SUPER_MAGIC`) in `src/unix/linux_like/linux/gnu/mod.rs` are defined as `c_long`, when they should be `c_uint` on s390x.
This ends up biting me [here](https://github.com/kata-containers/cgroups-rs/blob/master/src/hierarchies.rs#L231).
Thus, I suggest the attached change to only define these constants for architectures other than s390x and instead define them as uint for s390x.
This is safe since none of the constants are any wider than 32bit.
Please let me know if you think this could be done more elegantly.
Previously, statfs MAGIC constants like EXT4_SUPER_MAGIC were defined as c_long
for linux-gnu, whereas a statfs f_type is a c_uint on s390x. This commit
exempts these definitions from s390x and instead defines these constants as
c_uint on s390x. This is safe as none of these constants are wider than 32bit.
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
Make si_status method more compatible
Now that [this PR](https://github.com/rust-lang/libc/pull/1858/files) has been merged, `siginfo_t::si_status` is a method for some targets and a field on others. This PR adds the method on targets that already expose the field, which lets the method be used without target detection.
I think this change is backward compatible, but it would be better if someone else could confirm that. The struct would now have a method and a field with the same name on some targets. If that's incompatible, another method could be added that accesses the field or calls the method depending on the target, but this is cleaner.
Android: make statfs64.f_fsid public
This has been the case since the initial commit
a36da11fb9. But there is no reason to hide
this struct member specifically.
Yuki Okushi
bors
Ariadne Conill
Lucy Phipps
Jason King
James Lee
Jubilee Young
Dan Gohman
Sean Klein
Jonah Petri
Niels Sascha Reedijk
William Manley
Max Reitz
William Manley
Alexander Batischev
Thomas de Zeeuw
Guillaume Gomez
kellda
Amanieu d'Antras
Alan Somers
Thiébaud Weksteen
Josh Triplett
Patrick Mooney
Sergio Lopez
Amanieu d'Antras
Sébastien Marie
Tamir Duberstein
Isaac Woods
Damian Jarek
Benedikt Steinbusch
kolapapa
dylni
Sam Balana
Jakob Naucke
Luca Barbato
Ondrej Perutka
whitequark