Previously, the `guard::init()` and `guard::current()` functions were
returning a `usize` address representing the top of the stack guard,
respectively for the main thread and for spawned threads. The `SIGSEGV`
handler on `unix` targets checked if a fault was within one page below
that address, if so reporting it as a stack overflow.
Now `unix` targets report a `Range<usize>` representing the guard
memory, so it can cover arbitrary guard sizes. Non-`unix` targets which
always return `None` for guards now do so with `Option<!>`, so they
don't pay any overhead.
For `linux-gnu` in particular, the previous guard upper-bound was
`stackaddr + guardsize`, as the protected memory was *inside* the stack.
This was a glibc bug, and starting from 2.27 they are moving the guard
*past* the end of the stack. However, there's no simple way for us to
know where the guard page actually lies, so now we declare it as the
whole range of `stackaddr ± guardsize`, and any fault therein will be
called a stack overflow. This fixes#47863.
Only link res_init() on GNU/*nix
To workaround a bug in glibc <= 2.26 lookup_host() calls res_init() based on the glibc version detected at runtime. While this avoids calling res_init() on platforms where it's not required we will still end up linking against the symbol.
This causes an issue on macOS where res_init() is implemented in a separate library (libresolv.9.dylib) from the main libc. While this is harmless for standalone programs it becomes a problem if Rust code is statically linked against another program. If the linked program doesn't already specify -lresolv it will cause the link to fail. This is captured in issue #46797
Fix this by hooking in to the glibc workaround in `cvt_gai` and only activating it for the "gnu" environment on Unix This should include all glibc platforms while excluding musl, windows-gnu, macOS, FreeBSD, etc.
This has the side benefit of removing the #[cfg] in sys_common; only unix.rs has code related to the workaround now.
Before this commit:
```shell
> cat main.rs
use std::net::ToSocketAddrs;
#[no_mangle]
pub extern "C" fn resolve_test() -> () {
let addr_list = ("google.com.au", 0).to_socket_addrs().unwrap();
println!("{:?}", addr_list);
}
> rustc --crate-type=staticlib main.rs
> clang libmain.a test.c -o combined
Undefined symbols for architecture x86_64:
"_res_9_init", referenced from:
std::net::lookup_host::h93c17fe9ad38464a in libmain.a(std-826c8d3b356e180c.std0.rcgu.o)
ld: symbol(s) not found for architecture x86_64
clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)
```
Afterwards:
```shell
> rustc --crate-type=staticlib main.rs
> clang libmain.a test.c -o combined
> ./combined
IntoIter([V4(172.217.25.131:0)])
```
Fixes #46797
To workaround a bug in glibc <= 2.26 lookup_host() calls res_init()
based on the glibc version detected at runtime. While this avoids
calling res_init() on platforms where it's not required we will still
end up linking against the symbol.
This causes an issue on macOS where res_init() is implemented in a
separate library (libresolv.9.dylib) from the main libc. While this is
harmless for standalone programs it becomes a problem if Rust code is
statically linked against another program. If the linked program doesn't
already specify -lresolv it will cause the link to fail. This is
captured in issue #46797
Fix this by hooking in to the glibc workaround in `cvt_gai` and only
activating it for the "gnu" environment on Unix This should include all
glibc platforms while excluding musl, windows-gnu, macOS, FreeBSD, etc.
This has the side benefit of removing the #[cfg] in sys_common; only
unix.rs has code related to the workaround now.
As discussed in #47268, libstd isn't ready to have certain functionality
disabled yet. Follow wasm's approach of adding no-op modules for all of
the features that we can't implement.
I've placed all of those shims in a shims/ subdirectory, so we (the
CloudABI folks) can experiment with removing them more easily. It also
ensures that the code that does work doesn't get polluted with lots of
useless boilerplate code.
Though CloudABI is strongly inspired by POSIX, its absence of features
that don't work well with capability-based sandboxing makes it different
enough that adding bits to sys/unix will make things a mess. This change
therefore adds CloudABI specific platform code under sys/cloudabi and
borrows parts from sys/unix that can be used without changes.
One of the goals of this implementation is to build as much as possible
directly on top of CloudABI's system call layer, as opposed to using the
C library. This is preferred, as the system call layer is supposed to be
stable, whereas the C library ABI technically is not. An advantage of
this approach is that it allows us to implement certain interfaces, such
as mutexes and condition variables more optimally. They can be lighter
than the ones provided by pthreads.
This change disables some modules that cannot realistically be
implemented right now. For example, libstd's pathname abstraction is not
designed with POSIX *at() (e.g., openat()) in mind. The *at() functions
are the only set of file system APIs available on CloudABI. There is no
global file system namespace, nor a process working directory.
Discussions on how to port these modules over are outside the scope of
this change.
Apart from this change, there are still some other minor fixups that
need to be made to platform independent code to make things build. These
will be sent out separately, so they can be reviewed more thoroughly.
These automatically generated Rust source files allow us to invoke
system calls within CloudABI processes. These will be used by libstd to
implement primitives for I/O, threading, etc.
These source files are normally part of the 'cloudabi' crate. In the
case of libstd, we'd better copy them into the source tree, as having
external dependencies in libstd is a bit messy. Original source files
can be found here:
https://github.com/NuxiNL/cloudabi/tree/master/rust
Replace empty array hack with repr(align)
As a side effect, this fixes the warning about repr(C, simd) that has been reported during x86_64 windows builds since #47111 (see also: #47103)
r? @alexcrichton
Redox - Implement rename using new system call
This does the following:
- Update syscall module to match upstream
- Implement rename using new system call
- Make readlink and symlink utilize O_CLOEXEC
- Make readlink and symlink not leave dangling file handles on failure
Convert warning about `*const _` to a future-compat lint
#46664 was merged before I could convert the soft warning about method lookup on `*const _` into a future-compatibility lint. This PR makes that change.
fixes#46837
tracking issue for the future-compatibility lint: #46906
r? @arielb1
Use the CTL_KERN.KERN_PROC_ARGS.-1.KERN_PROC_PATHNAME sysctl in
preference over the /proc/curproc/exe symlink.
Additionally, perform more validation of aformentioned symlink.
Particularly on pre-8.x NetBSD this symlink will point to '/' when
accurate information is unavailable.
Provides the following conversion implementations:
* `From<`{`CString`,`&CStr`}`>` for {`Arc`,`Rc`}`<CStr>`
* `From<`{`OsString`,`&OsStr`}`>` for {`Arc`,`Rc`}`<OsStr>`
* `From<`{`PathBuf`,`&Path`}`>` for {`Arc`,`Rc`}`<Path>`
This commit alters how we compile LLVM by default enabling the WebAssembly
backend. This then also adds the wasm32-unknown-unknown target to get compiled
on the `cross` builder and distributed through rustup. Tests are not yet enabled
for this target but that should hopefully be coming soon!
Turns out ThinLTO was internalizing this symbol and eliminating it. Worse yet if
you compiled with LTO turns out no TLS destructors would run on Windows! The
`#[used]` annotation should be a more bulletproof implementation (in the face of
LTO) of preserving this symbol all the way through in LLVM and ensuring it makes
it all the way to the linker which will take care of it.
This commit adds a new target to the compiler: wasm32-unknown-unknown. This
target is a reimagining of what it looks like to generate WebAssembly code from
Rust. Instead of using Emscripten which can bring with it a weighty runtime this
instead is a target which uses only the LLVM backend for WebAssembly and a
"custom linker" for now which will hopefully one day be direct calls to lld.
Notable features of this target include:
* There is zero runtime footprint. The target assumes nothing exists other than
the wasm32 instruction set.
* There is zero toolchain footprint beyond adding the target. No custom linker
is needed, rustc contains everything.
* Very small wasm modules can be generated directly from Rust code using this
target.
* Most of the standard library is stubbed out to return an error, but anything
related to allocation works (aka `HashMap`, `Vec`, etc).
* Naturally, any `#[no_std]` crate should be 100% compatible with this new
target.
This target is currently somewhat janky due to how linking works. The "linking"
is currently unconditional whole program LTO (aka LLVM is being used as a
linker). Naturally that means compiling programs is pretty slow! Eventually
though this target should have a linker.
This target is also intended to be quite experimental. I'm hoping that this can
act as a catalyst for further experimentation in Rust with WebAssembly. Breaking
changes are very likely to land to this target, so it's not recommended to rely
on it in any critical capacity yet. We'll let you know when it's "production
ready".
---
Currently testing-wise this target is looking pretty good but isn't complete.
I've got almost the entire `run-pass` test suite working with this target (lots
of tests ignored, but many passing as well). The `core` test suite is still
getting LLVM bugs fixed to get that working and will take some time. Relatively
simple programs all seem to work though!
---
It's worth nothing that you may not immediately see the "smallest possible wasm
module" for the input you feed to rustc. For various reasons it's very difficult
to get rid of the final "bloat" in vanilla rustc (again, a real linker should
fix all this). For now what you'll have to do is:
cargo install --git https://github.com/alexcrichton/wasm-gc
wasm-gc foo.wasm bar.wasm
And then `bar.wasm` should be the smallest we can get it!
---
In any case for now I'd love feedback on this, particularly on the various
integration points if you've got better ideas of how to approach them!
Use getrandom syscall for all Linux and Android targets.
I suppose we can use it in all Linux and Android targets. In function `is_getrandom_available` is checked if the syscall is available (getrandom syscall was add in version 3.17 of Linux kernel), if the syscall is not available `fill_bytes` fallback to reading from `/dev/urandom`.
Update libc to include getrandom related constants.
Redox: Use futex timeout to implement CondVar::wait_timeout
`CondVar::wait_timeout` is implemented by supplying a `TimeSpec` pointer to `futex`. In addition, all calls to `unimplemented!()` have been removed from the Redox `sys` module.
Related to https://github.com/rust-lang/rust/pull/45892
This commit removes usage of the `libc` crate in "portable" modules like
those at the top level and `sys_common`. Instead common types like `*mut
u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as
switching to platform-specific functions like `sys::strlen` instead of
`libc::strlen`.
This commit moves the `f32::cmath` and `f64::cmath` modules into the
`sys` module. Note that these are not publicly exported modules, simply
implementation details. These modules are already platform-specific with
shims on MSVC and this is mostly just a reflection of that reality. This
should also help cut down on `#[cfg]` traffic if platforms are brought on
which don't directly support these functions.
