about summary refs log tree commit diff
path: root/src/libstd/sys/cloudabi
AgeCommit message (Collapse)AuthorLines
2018-04-13std: Minimize size of panicking on wasmAlex Crichton-0/+4
This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
2018-04-12Import the `alloc` crate as `alloc_crate` in stdSimon Sapin-1/+1
… to make the name `alloc` available.
2018-03-24Fix build on non-Unix platformsTatsuyuki Ishi-0/+1
2018-03-03Move process::ExitCode internals to sysScott McMurray-0/+12
Now begins the saga of fixing compilation errors on other platforms...
2018-01-31Use a range to identify SIGSEGV in stack guardsJosh Stone-2/+3
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.
2018-01-26Print inlined functions on WindowsJohn Kåre Alsaker-0/+1
2018-01-11Add shims for modules that we can't implement on CloudABI.Ed Schouten-0/+979
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.
2018-01-11Implement libstd for CloudABI.Ed Schouten-0/+1154
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.
2018-01-11Import the CloudABI system call bindings into the libstd tree.Ed Schouten-0/+2898
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