This target is [being proposed][LINK] int he rust-lang/rust repository
and this is intended to get coupled with that proposal. The definitions
here all match the upstream reference-sysroot definitions and the
functions all match the reference sysroot as well. The linkage here is
described more in detail on the Rust PR itself, but in general it's
similar to musl.
Automatic verification has been implemented in the same manner as other
targets, and it's been used locally to develop this PR and catch errors
in the bindings already written (also to help match the evolving sysroot
of wasi). The verification isn't hooked up to CI yet though because
there is no wasi target distributed via rustup just yet, but once that's
done I'll file a follow-up PR to execute verification on CI.
[LINK]:
cleanup libc-test for OpenBSD
here a cleanup for libc-test for OpenBSD
Some elements (compat for old and now unsupported OpenBSD versions) could be removed, but I think it is better to address them after this PR is merged.
the testsuite for OpenBSD still pass with it (well, with #1280)
r? @gnzlbg
This cleans up the build.rs of `libc-test` for apple targets.
I wanted to update the docker containers of some targets so that we can start
testing newer currently-skipped APIs properly, but it is impossible to figure
out which headers and APIs are skipped for each target.
This PR separates the testing of apple targets into its own self-contained
function. This allows seeing exactly which headers are included, and which items
are skipped. A lot of work will be required to separate the testing of all major
platforms and make the script reasonable.
During the clean up, I discovered that, at least for apple targets, deprecated
but not removed APIs are not tested. I re-enabled testing for those, and fixed
`daemon`, which was not properly linking its symbol. I also added the
`#[deprecated]` attribute to the `#[deprecated]` APIs of the apple targets. The
attribute is available since Rust 1.9.0 and the min. Rust version we support is
Rust 1.13.0.
Many other APIs are also currently not tested "because they are weird" which I
interpret as "the test failed for an unknown reason", as a consequence:
* the signatures of execv, execve, and execvp are incorrect (see
https://github.com/rust-lang/libc/issues/1272)
* the `sig_t` type is called `sighandler_t` in libc for some reason:
https://github.com/rust-lang/libc/issues/1273
This probably explains why some other things, like the
`sa_handler`/`sa_sigaction` fields of `sigaction` were skipped. The field is
actually a union, which can be either a `sig_t` for the `sa_handler` field, or
some other type for the `sa_sigaction` field, but because the distinction was
not made, the field was not checked.
The latest ctest version can check volatile pointers, so a couple of skipped
tests are now tested using this feature.
Since these are defined in C as macros, they must be reimplemented in
libc as Rust functions. They're hard to get exactly right, and they
vary from platform to platform. The test builds custom C code that uses
the real macros, and compares its output to the Rust versions' output
for various inputs.
Skip the CMSG_NXTHDR test on sparc64 linux because it hits a Bus Error.
Issue #1239
Skip the entire cmsg test program on s390x because it dumps core
seemingly before the kernel finishes booting.
Issue #1240
RFC 2235 - Implement PartialEq,Eq,Hash,Debug for all types
First pass at implementing [RFC2235](https://github.com/rust-lang/rfcs/blob/master/text/2235-libc-struct-traits.md). I just started with `PartialEq`/`Eq` and tested locally on my x64 Linux system. Definitely going to run into other types for other platforms that need this treatment, but thought I'd start small.
Open question is whether this should also rely on the `align` feature, which should improve which types can be auto-derived versus manually implemented (as it removed a lot of odd-sized padding arrays). My first pass here doesn't do that, but I might test it out to see if it does simplify quite a few structs. I think it might also be nice to have as it makes it easier for contributors to add new structs.
Part of rust-lang/rust#57715
Bump ctest from 0.2.6 to 0.2.7
Bumps [ctest](https://github.com/alexcrichton/ctest) from 0.2.6 to 0.2.7.
<details>
<summary>Commits</summary>
- See full diff in [compare view](https://github.com/alexcrichton/ctest/commits/0.2.7)
</details>
<br />
[![Dependabot compatibility score](https://api.dependabot.com/badges/compatibility_score?dependency-name=ctest&package-manager=cargo&previous-version=0.2.6&new-version=0.2.7)](https://dependabot.com/compatibility-score.html?dependency-name=ctest&package-manager=cargo&previous-version=0.2.6&new-version=0.2.7)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme
Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)
Finally, you can contact us by mentioning @dependabot.
</details>
This commit prepares the `libc` crate to be included directly into the
standard library via crates.io. More details about this can be found on
rust-lang/rust#56092, but the main idea is that this crate now depends
on core/compiler-builtins explicitly (but off-by-default).
The main caveat here is that this activates `no_core` when building as
part of libstd, which means that it needs to explicitly have an `iter`
and `option` module for the expansion of `for` loops to work.
Linux 4.18 added support for SIGSYS info in signalfd. Add the new
fields to signalfd_siginfo.
While the kernel has support for these new fields now, no libc has
shipped a release with the new signalfd fields.
Theoretically test statics
There are none of them in `libc` except for `__progname` on Android, but
that one cannot be tested because it's not present in any header files.
added EPOLL(5) for Illumos (Solaris fork)
EPOLL(5) is being used in crates like mio and iovec , this change allows those crates and other that depends on EPOLL(5) to be built in illumos systems.
These aren't exposed on non-MIPS musl targets, but since they're
part of a kernel API, they're still applicable, so we just don't
test them there but expose them anyways.
Initial fixes for linux x32
Tested with a local build of rustc. The main test can be compiled but fails to execute (receives SIGTRAP, which I think in this case indicates memory violation, I will open an issue in the rustc repo).
This PR is important because it fixes the definition of `c_long` and `c_ulong`. Without these fixes, rustc crash with the error:
```
Cannot emit physreg copy instruction
UNREACHABLE executed at /checkout/src/llvm/lib/Target/X86/X86InstrInfo.cpp:5778!
```
Related https://github.com/rust-lang/rust/issues/37976
Rebase of #610 and also move emscripten up much higher in the hierarchy to
ensure that it doesn't have too much of a ripple effect on other platforms.
This involved moving down a good number of definitions, but hopefully was done
with care to not break anything!
We now create an additional binary `linux_fcntl` for testing this
since there are header conflicts when including all necessary headers.
This binary is run on all platforms even though it's empty on all non-
Android/non-Linux platforms.
Testing has been switched from a custom binary to using a runner-less
test (or pair of tests). This means that for local development a simple
`cd libc-test && cargo test` will run all the tests. CI has also been
updated here to reflect that.
It's now broken due to changes in the `gcc` crate and having a too-old compiler,
and in general it's unfortunately architecturally so different from the other
test frameworks that it's difficult to maintain over time.
Add KERN_USERMOUNT and KERN_ARND to don't check list on OpenBSD
These [two constants are no longer in OpenBSD](3f376b0849/sys/sys/sysctl.h (L133-L140)). They were preventing the the tests from passing. With this change the test now pass:
```
CC=egcc cargo run
Compiling libc v0.2.29 (file:///home/vagrant/libc)
Compiling libc-test v0.1.0 (file:///home/vagrant/libc/libc-test)
Finished debug [unoptimized + debuginfo] target(s) in 11.7 secs
Running `/home/vagrant/libc/target/debug/libc-test`
RUNNING ALL TESTS
PASSED 5935 tests
```
They are still present in bitrig so I moved them there.
It needs to be skipped during testing because there's no way to include
a combination of headers that will expose it without giving a "type has
already been defined" error.
Adding missing structs from linux/user.h
Adding structs from linux/user.h (or sys/user.h depending on OS version). This adds the linux user_regs_struct and user struct from sys/user.h into libc for x86 and x86_64. Also, bumping the version number.
As an aside, I was wondering if this was also the right place to add the bit offsets for the [EFLAGS register ](https://en.wikibooks.org/wiki/X86_Assembly/X86_Architecture#EFLAGS_Register)? These aren't defined anywhere in the linux system libraries instead the definition seems to just be in the x86 and x86_64 documentation but they are useful for anyone looking to interpret eflags. If libc is the right place for these constants I'd like the opportunity to add them before it's merged in. :)
Fixed the issues that prevented the libc_tests that are generated from passing. Also, fixed struct names and types to be representative of the linux source files.
Use NOCANCEL variants for close on Mac
The default `close()` on OS X does not provide clear errors, instead the `$NOCANCEL` variants should be used. These are available as of OS X 10.6 onwards.
Fixes#595.
Steps towards support for musl-unknown-linux-uclibc
Hello! I've been working towards resolving https://github.com/rust-lang/libc/issues/361 , this PR compiles successfully with a newish compiler (with some minor fixes in `gcc`, `ctest`), and all the tests pass for `libc-ctest`. Basically most of the undefined functions, constants, and structs were just removed from the ctest, and then any constants that weren't correct were fixed. Would it make more sense to conditionally remove them from libc? I wasn't sure when it was appropriate to skip the test for it instead of removing the function/constants, so I just removed all the tests for now because that was a little easier than hunting them down. I'm also guessing the way some of the constants were conditionally set wasn't the correct style, would you guys have any advice on how to do it more correctly? Lemme know how it looks!
There is a compatibility issue regarding the type of a flag parameter:
int vs uint. Linux does declare the syscall to use uint and musl
followed it, but it is incompatible with other POSIX recv*/send*
syscalls. So it seems to be wise to follow the glibc version of
prototypes with int.
Signed-off-by: NODA, Kai <nodakai@gmail.com>
Add x86_64-linux-android support
When rust add support for x86_64-linux-android, the tests may be run with:
`rustup target add x86_64-linux-android && bash ci/run-docker.sh x86_64-linux-android`.
Android x86_64 emulator does not work without hardware acceleration, so we are not able to run tests on travis.
- some tests are failing
- remove readlink, timegm and sig* functions in favor of the
unix/mod.rs definitions
- remove time64_t (it is not defined for aarch64)
- move some definitions to android/b32.rs and create appropriated
definitions in android/b64.rs
This helps caching between runs and can help speed up turnaround time for
various operations. The old android container didn't work out for some reason
due to permissions so the definition has now been vendored locally to just
rebuild it each time.
FreeBSD svn r262489 removed some *_MAXID definitions in sys/sysctl.h. They never
should've been used outside of the FreeBSD base system anyway. Mark them as
deprecated, hide them from the API docs, and disable their tests.
r273250 removed MAP_RENAME and MAP_NORESERVE, flags used by mmap(2), but old
binaries that use them will still work. Suppress their test errors.
r294930 changed stack_t.ss_sp from a char* to a void*. Suppress its test error.
Add more architectures to libc-test
* `i686-unknown-linux-musl`
* `powerpc-unknown-linux-gnu`
* `powerpc64-unknown-linux-gnu`
cc @japaric
cc https://github.com/rust-lang/rust/issues/36006
Sadly, the sysinfo struct varies slightly between Musl and Glibc / Bionic.
This means that users need to be careful when using the uptime, and should
always cast it to a signed value. Why uptime can be signed is beyond me...
Removed CODE, as its definition and name varies too wildy and I
have no current code using it to test permutations with.
Moved LOG_NFACILITIES down, as Mac OS X defines this value
differently.
Added Mac OS X specific LOG_* facilities.
Added FreeBSD / DragonFly BSD specific LOG_* facilities.
Moved LOG_PERROR down, as all platforms bar Solaris define this.
Moved LOG_CRON down, as Solaris defines this with a different value.
Moved LOG_AUTHPRIV and LOG_FTP down, as all platforms bar Solaris
define these.
Looks like Solaris is suffering from the bit rot of commercial Unix...
As with `getrlimit` and `setrlimit`, the glibc wrappers have a non-`int`
for the `resource` argument, eg:
extern int prlimit (__pid_t __pid, enum __rlimit_resource __resource,
const struct rlimit *__new_limit,
struct rlimit *__old_limit) __THROW;
in order to advise contributors to locally test their patches.
Also update ctest to include a fix on rerun-if-changed so that human
developers doing trial & error can properly test their latest code.
Signed-off-by: NODA, Kai <nodakai@gmail.com>
Use now available link name "signal" instead of "bsd_signal"
On android, the `bsd_signal` is gone, the `signal` is available.
While this is the most obvious solution, I am not sure of a few things:
- How are we going to keep compatibility with older NDKs where `signal` does not exist;
- Was something dependent on this being different on android and thus would break (for example, the rust compiler uses this function, so it may break somewhere).
Fixes#236.