| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
port libstd to it.
As a start, the port uses the simplest possible configuration (no jemalloc, abort on panic)
and makes use of existing Unix-specific code wherever possible.
It adds targets for x86_64 (current main HermitCore platform) and aarch64 (HermitCore platform
under development).
Together with the patches to "liblibc" and "llvm", this enables HermitCore applications to be
written in Rust.
|
|
|
|
While currently only NetBSD seems to be affected, all systems
implementing PAX MPROTECT in strict mode need this treatment,
and it does not hurt others.
|
|
On NetBSD the initial mmap() protection of a mapping can not be made
less restrictive with mprotect().
So when mapping a stack guard page, use the maximum protection
we ever want to use, then mprotect() it to the permission we
want it to have initially.
|
|
… to make the name `alloc` available.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Resolves #46137.
|
|
|
|
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`.
|
|
|
|
The default min stack size value is smaller on l4re and therefore
this value has to be different depending on the platform.
|
|
|
|
This commit adds the needed modifications to compile the std crate
for the L4 Runtime environment (L4Re).
A target for the L4Re was introduced in commit:
c151220a84e40b65e45308cc0f3bbea4466d3acf
In many aspects implementations for linux also apply for the L4Re
microkernel.
Two uncommon characteristics had to be resolved:
* L4Re has no network funktionality
* L4Re has a maximum stacksize of 1Mb for threads
Co-authored-by: Sebastian Humenda <sebastian.humenda@tu-dresden.de>
|
|
Also add to the documentation that the `join` method can panic.
cc #34971
cc #43539
|
|
Linux doesn't allocate the whole stack right away, and the kernel has
its own stack-guard mechanism to fault when growing too close to an
existing mapping. If we map our own guard, then the kernel starts
enforcing a rather large gap above that, rendering much of the possible
stack space useless.
Instead, we'll just note where we expect rlimit to start faulting, so
our handler can report "stack overflow", and trust that the kernel's own
stack guard will work.
Fixes #43052.
|
|
Prefer FIXME to TODO
|
|
Adds support for the x86_64-unknown-fuchsia target, which covers the
Fuchsia operating system.
|
|
|
|
|
|
|
|
* Hand rebased from Niels original work on 1.9.0
|
|
|
|
|
|
The `use ffi::CStr` in `unix/thread.rs` was previously guarded, but now
all platforms need it for `Thread::set_name()`. Newlib and Solaris do
nothing here, as they have no way to set a thread name, but they still
define the same method signature.
|
|
|
|
|
|
|
|
src/libstd/sys/unix/thread.rs
Implement several stack-related functions on FreeBSD
src/libstd/sys/unix/stack_overflow.rs
Fix a comment
|
|
Previously, the thread name (&str) was converted to a CString in the
new thread, but outside unwind::try, causing a panic to continue into FFI.
This patch changes that behaviour, so that the panic instead happens
in the parent thread (where panic infrastructure is properly set up),
not the new thread.
This could potentially be a breaking change for architectures who don't
support thread names.
Signed-off-by: David Henningsson <diwic@ubuntu.com>
|
|
Here's another go at adding emscripten support. This needs to wait again on new [libc definitions](https://github.com/rust-lang-nursery/libc/pull/122) landing. To get the libc definitions right I had to add support for i686-unknown-linux-musl, which are very similar to emscripten's, which are derived from arm/musl.
This branch additionally removes the makefile dependency on the `EMSCRIPTEN` environment variable by not building the unused compiler-rt.
Again, this is not sufficient for actually compiling to asmjs since it needs additional LLVM patches.
r? @alexcrichton
|
|
|
|
Backtraces, and the compilation of libbacktrace for asmjs, are disabled.
This port doesn't use jemalloc so, like pnacl, it disables jemalloc *for all targets*
in the configure file.
It disables stack protection.
|
|
Right now we only attempt to call one symbol which my not exist everywhere,
__pthread_get_minstack, but this pattern will come up more often as we start to
bind newer functionality of systems like Linux.
Take a similar strategy as the Windows implementation where we use `dlopen` to
lookup whether a symbol exists or not.
|
|
|
|
|
|
|
|
Looks like the rumprun build has bitrotted over time, so this includes some libc
fixes and some various libstd fixes which gets it back to bootstrapping.
|
|
The deny(warnings) attribute is now enabled for tests so we need to weed out
these warnings as well.
|
|
Signed-off-by: Peter Atashian <retep998@gmail.com>
|
