| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| | |
Bump up libc version to 0.2.87
r? `@ghost`
In order to unblock https://github.com/rust-lang/rust/issues/82400.
This also closes #2065.
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Replace `x86_64-sun-solaris` with `x86_64-pc-solaris`
Address the changes by https://github.com/rust-lang/rust/pull/82216. I didn't add `x86_64-sun-solaris` as it's now deprecated.
r? `@ghost`
|
| |/ |
|
| |\
| |
| |
| |
| |
| | |
Add definition of SELINUX_MAGIC
This commit adds the definition of SELINUX_MAGIC.
|
| | |
| |
| |
| | |
Signed-off-by: Kenta Tada <Kenta.Tada@sony.com>
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
Remove CI support for `x86_64-rumprun-netbsd`
That target has been removed by https://github.com/rust-lang/rust/pull/82594.
This is intended to unblock CI and we could drop the actual library support for it like CloudABI.
r? `@ghost`
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
Move `s390x-unknown-linux-musl` to build.sh
Fixes #2085
r? `@ghost`
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| | |
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
|
| | |
| |
| | |
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
use GNU/Linux siginfo_t on Android
Bionic uses an unchanged siginfo.h from the upstream linux so why not? :)
I literally just copied everything with siginfo_t from unix/linux_like/linux/gnu/mod.rs to unix/linux_like/android/mod.rs
|
| |/ /
| |
| |
| | |
needs testing
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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` :eyes:) 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` :eyes:) 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
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Add additional illumos and Solaris constants
This adds some additional constants for `fcntl(2)` and `setsockopt(3SOCKET)`.
|
| | | | | |
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Add FreeBSD BPF structures
This PR adds BPF structures that are common between [FreeBSD 11](https://github.com/freebsd/freebsd-src/blob/release/11.0.0/sys/net/bpf.h), [FreeBSD 12](https://github.com/freebsd/freebsd-src/blob/release/12.0.0/sys/net/bpf.h), [FreeBSD mainline/13](https://github.com/freebsd/freebsd-src/blob/main/sys/net/bpf.h) and [DragonFlyBSD 5.9](https://github.com/DragonFlyBSD/DragonFlyBSD/blob/v5.9.0/sys/net/bpf.h).
It also fixes the definition of `BPF_ALIGNMENT`, which should be equal to `sizeof(long)`, which is `4` on 32bit FreeBSD.
https://www.freebsd.org/cgi/man.cgi?query=arch&sektion=7
> All supported ABIs can be divided into two groups:
> * ILP32: `int`, `long`, `void *` types machine representations all have 4-byte size.
> * LP64: `int` type machine representation uses 4 bytes, while `long` and `void *` are 8 bytes.
I introduced the private `SIZEOF_LONG` const, since I didn't want to introduce a dependency on rust 1.24+ by depending on `libc_const_size_of`.
These changes allow my experimental crate to build on FreeBSD: https://github.com/jbit/powerline
|
| | | | | |
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \
| |/
|/|
| |
| |
| | |
Add O_DIRECTORY to solarish
FYI `@pfmooney` . I was trying to port [nix](https://crates.io/crates/nix) to illumos, and noticed this in the illumos-gate [headers](https://github.com/illumos/illumos-gate/blob/221e47fb90c5fcfe7add9a33f6c915ee5253ece9/usr/src/uts/common/sys/fcntl.h), but not in libc.
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
