sparc64-linux support #483
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
For values that need to be changed for #[cfg]'d, can we just push those down the module hierarchy? It's fine to have a ton of duplication, that's what libc is for! |
|
Looks good to me! Travis has a few failures though? |
|
should be ready to go this time |
|
@bors: r+ |
|
📌 Commit 67615b4 has been approved by |
bors
added a commit
that referenced
this pull request
Jan 1, 2017
sparc64-linux support
This needs to be "cleaned" up to use modules instead of a bunch of `cfg`s ...
Sadly, sparc64 constants are very different from other architectures so cleaning this will result in a bunch of duplication, I think.
While working on this, I was wondering why the constants are not written like this:
``` rust
// linux/mod.rs
const COMMON: ::c_int = 3;
cfg_if! {
if #[cfg(target_arch = "sparc64")] {
const FOO: ::c_int = 1;
} else if #[cfg(any(target_arch = "mips64", target_arch = "x86_64"))] {
const FOO: ::c_int = 2;
} else {
// unsupported/unknown architecture
}
}
```
I think this might result in less duplicated code. @alexcrichton Has something like that ^ been attempted before?
|
☀️ Test successful - status-appveyor, status-travis |
bors
added a commit
to rust-lang/rust
that referenced
this pull request
Jan 1, 2017
sparc64-linux support This is built on top of #38656 and depends on rust-lang/libc#483 Hello world works. The libc-test test suite passes. `panic!` doesn't fully work: ``` $ qemu-sparc64-static ./panic thread 'main' panicked at 'explicit panic', panic.rs:1 note: Run with `RUST_BACKTRACE=1` for a backtrace. Illegal instruction (core dumped) ``` Backtraces don't work either, probably related to the previous point: ``` $ export RUST_BACKTRACE=1 $ qemu-sparc64-static ./panic thread 'main' panicked at 'explicit panic', panic.rs:1 stack backtrace: Illegal instruction (core dumped) ``` r? @alexcrichton @jakllsch Does panicking / backtraces work on sparc64-netbsd? cc @glaubitz
Susurrus
pushed a commit
to Susurrus/libc
that referenced
this pull request
Mar 26, 2017
Add POSIX AIO support POSIX AIO is a standard for asynchronous file I/O. Read, write, and fsync operations can all take place in the background, with completion notification delivered by a signal, by a new thread, by kqueue, or not at all. The SigEvent class, used for AIO notifications among other things, is also added.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This needs to be "cleaned" up to use modules instead of a bunch of
cfgs ...Sadly, sparc64 constants are very different from other architectures so cleaning this will result in a bunch of duplication, I think.
While working on this, I was wondering why the constants are not written like this:
I think this might result in less duplicated code. @alexcrichton Has something like that ^ been attempted before?