Add TIOCGWINSZ accessor to solaris module
Signed-off-by: Ian Henry <ihenry@chef.io>
I recently noticed downstream that these request values were unavailable and needed for things like [the pb crate](https://github.com/a8m/pb). To get access to the request value I ran the following simple C code:
```
#include <sys/ioctl.h>
#include <stdio.h>
#include <sys/termios.h>
int main(int argc, char **argv) {
printf("Code: 0x%04lx\n", TIOCGWINSZ);
printf("Code: 0x%04lx\n", TIOCSWINSZ);
return 0;
}
```
To then validate the change I ran the following simple rust:
```
extern crate libc;
use libc::{ioctl, winsize, STDOUT_FILENO, TIOCGWINSZ};
fn main() {
let mut wsize = winsize {
ws_row: 0,
ws_col: 0,
ws_xpixel: 0,
ws_ypixel: 0,
};
unsafe {
ioctl(STDOUT_FILENO, TIOCGWINSZ, &mut wsize);
}
println!("Sizes: {{ rows: {}, cols: {}, xpixel: {}, ypixel: {} }}",
wsize.ws_row,
wsize.ws_col,
wsize.ws_xpixel,
wsize.ws_ypixel);
}
```
The futimes(), lutimes(), mq_timedreceive(), and mq_timedsend()
functions were linking against legacy library symbols that need 32-bit
time_t in structures, resulting in an ABI mismatch with 64-bit time_t.
Add libc definitions for Megaton-Hammer, a Switch Homebrew toolchain
I'm working on a pure-rust toolchain to write homebrew for the Nintendo Switch called [Megaton-Hammer](http://github.com/megatonhammer/megaton-hammer). I'm hoping to get those definitions upstreamed to simplify my life :).
This toolchain does not depend on a C compiler or a libc (it reimplements everything in rust) - but given many crates in the Rust ecosystem rely on the libc crate for the definition of various common types, this is what I came up with.
I was wondering what a good target triple would be ? I currently gate the implementation behind `target_os = "switch"`, but if this goes upstream I figure that might cause trouble for people using the Nintendo SDK (they might already be using `target_os = "switch"` for some things). Would it be better to go with `target_env = "megatonhammer"`?
Bump version to 0.2.43
Would be nice to have the new align feature from #1044 available for general use. But mostly I want this released since I have problems using the align feature for a PR on libstd, and I suspect it's somehow because I try to use an unpublished libc (https://github.com/rust-lang/rust/pull/52872).
illumos epoll_event struct should be packed
While attempting to run `cargo test` within the mio crate on illumos I noticed a number of the tests fail. Digging into the various epoll calls I discovered that the epoll_event struct was misaligned due to extra padding. The fix is to pack the epoll_event struct with the same compiler setting that the linux variant is using.
A simple rust example that demonstrates the issue:
```rust
extern crate libc;
use libc::epoll_event;
use std::mem;
fn main() {
println!("{}", mem::size_of::<u64>());
println!("{}", mem::size_of::<epoll_event>());
}
```
Running the above code on Linux results in:
```
8
12
```
while on illumos it currently results in:
```
8
16
```
Looking at the `test_close_on_drop` test from mio I traced the `epoll_ctl`
calls and saw the following:
```
[root@rustdev ~/src/mio]# dtrace -wn 'pid$target::epoll_ctl:entry {this->ev = arg3; printf("%d\n", arg2); print((struct epoll_event *)this->ev); stop()}' -c "/root/src/mio/target/debug/deps/test-109e1422fb40f621 test_close_on_drop"
dtrace: description 'pid$target::epoll_ctl:entry ' matched 1 probe
dtrace: allowing destructive actions
running 1 test
CPU ID FUNCTION:NAME
6 92874 epoll_ctl:entry 4
struct epoll_event * 0xfffffc7fee7feda8
test test_close_on_drop::test_close_on_drop ... test test_close_on_drop::test_close_on_drop has been running for over 60 seconds
6 92874 epoll_ctl:entry 6
struct epoll_event * 0xfffffc7fee7fee18
^[[A 6 92874 epoll_ctl:entry 7
struct epoll_event * 0xfffffc7fee7fee18
```
I dumped each of the epoll_event's with mdb:
```
[root@rustdev ~/src/mio]# mdb -Fp 219856
Loading modules: [ libumem.so.1 libc.so.1 ]
> 0xfffffc7fee7feda8::print
mdb: no symbol information for 0xfffffc7fee7feda8: no symbol corresponds to address
> 0xfffffc7fee7feda8::print struct epoll_event
{
events = 0x80000001
data = {
ptr = 0xfffffffffffffc7f
fd = 0xfffffc7f
u32 = 0xfffffc7f
u64 = 0xfffffffffffffc7f
}
}
>
[root@rustdev ~/src/mio]# prun 219856
[root@rustdev ~/src/mio]# mdb -Fp 219856
Loading modules: [ libumem.so.1 libc.so.1 ]
> 0xfffffc7fee7fee18::print struct epoll_event
{
events = 0x80000001
data = {
ptr = 0
fd = 0
u32 = 0
u64 = 0
}
}
>
[root@rustdev ~/src/mio]# prun 219856
[root@rustdev ~/src/mio]# mdb -Fp 2198
Loading modules: [ libumem.so.1 libc.so.1 ]
> 0xfffffc7fee7fee18::print struct epoll_event
{
events = 0x80000004
data = {
ptr = 0x100000000
fd = 0
u32 = 0
u64 = 0x100000000
}
}
```
The output from the last two `epoll_event`'s represent `Token(0)` the Client and `Token(1)` from the mio test. The first one however is from `AWAKEN` which is defined as `usize::MAX`. This value should be 18446744073709551615. However if we convert the hex value we see something else:
```
> 0xfffffffffffffc7f=E
18446744073709550719
```
Because of the extra 4 bytes of padding currently present in the illumos `epoll_event` definition the low order bits are picking up some junk from other memory.
All of the poll-related mio tests pass with this change. Two other tests are still failing, which appears to be caused by an OS bug, not a problem with mio or libc.
Add libc definitions for HermitCore (https://hermitcore.org)
HermitCore is based on lwIP, newlib, and pthread-embedded.
Some definitions are similar to other targets using newlib, however some are different enough to justify an own "hermit" port and not base on the existing "newlib" port.
