summary refs log tree commit diff
path: root/library/std/src/sys
AgeCommit message (Collapse)AuthorLines
2021-06-10Rollup merge of #84687 - a1phyr:improve_rwlock, r=m-ou-seYuki Okushi-58/+17
Multiple improvements to RwLocks This PR replicates #77147, #77380 and #84650 on RWLocks : - Split `sys_common::RWLock` in `StaticRWLock` and `MovableRWLock` - Unbox rwlocks on some platforms (Windows, Wasm and unsupported) - Simplify `RwLock::into_inner` Notes to reviewers : - For each target, I copied `MovableMutex` to guess if `MovableRWLock` should be boxed. - ~A comment says that `StaticMutex` is not re-entrant, I don't understand why and I don't know whether it applies to `StaticRWLock`.~ r? `@m-ou-se`
2021-06-01Support Android ndk versions `r23-beta3` and upTilmann Meyer-1/+0
Since android ndk version `r23-beta3`, `libgcc` has been replaced with `libunwind`. This moves the linking of `libgcc`/`libunwind` into the `unwind` crate where we check if the system compiler can find `libunwind` and fall back to `libgcc` if needed.
2021-06-01Multiple improvements to RwLocksBenoît du Garreau-58/+17
- Split `sys_common::RWLock` between `StaticRWLock` and `MovableRWLock` - Unbox `RwLock` on some platforms (Windows, Wasm and unsupported) - Simplify `RwLock::into_inner`
2021-05-26Rename opensbd to openbsdAlbert Ford-3/+3
2021-05-23Auto merge of #85490 - CDirkx:fix-vxworks, r=dtolnaybors-4/+30
Fix `vxworks` Some PRs made the `vxworks` target not build anymore. This PR fixes that: - #82973: copy `ExitStatusError` implementation from `unix`. - #84716: no `libc::chroot` available on `vxworks`, so for now don't implement `os::unix::fs::chroot`.
2021-05-23Rollup merge of #84758 - ChrisDenton:dllimport, r=dtolnayDylan DPC-166/+168
MSVC: Avoid using jmp stubs for dll function imports Windows import libraries contain two symbols for every function: `__imp_FunctionName` and `FunctionName` (where `FunctionName` is the name of the function to be imported). `__imp_FunctionName` contains the address of the imported function. This will be filled in by the Windows executable loader at runtime. `FunctionName` contains a jmp stub that simply jumps to the address given by `__imp_FunctionName`. E.g. it's a function that solely contains a single jmp instruction: ```asm jmp __imp_FunctionName ``` When using an external DLL function in Rust, by default the linker will link to FunctionName, causing a bit of indirection at runtime. In Microsoft's C++ it's possible to instead tell it to insert calls to the address in `__imp_FunctionName` by using the `__declspec(dllimport)` attribute. In Rust it's possible to get effectively the same behaviour using the `#[link]` attribute on `extern` blocks. ---- The second commit also merges multiple `extern` blocks into one block. This is because otherwise Rust will currently create duplicate linker arguments for each block. In this case having duplicates shouldn't matter much other than the noise when displaying the linker command.
2021-05-21Auto merge of #85060 - ChrisDenton:win-file-exists, r=yaahcbors-3/+37
Windows implementation of feature `path_try_exists` Draft of a Windows implementation of `try_exists` (#83186). The first commit reorganizes the code so I would be interested to get some feedback on if this is a good idea or not. It moves the `Path::try_exists` function to `fs::exists`. leaving the former as a wrapper for the latter. This makes it easier to provide platform specific implementations and matches the `fs::metadata` function. The other commit implements a Windows specific variant of `exists`. I'm still figuring out my approach so this is very much a first draft. Eventually this will need some more eyes from knowledgable Windows people.
2021-05-20Rollup merge of #85275 - CDirkx:memchr, r=m-ou-seGuillaume Gomez-2/+2
Move `std::memchr` to `sys_common` `std::memchr` is a thin abstraction over the different `memchr` implementations in `sys`, along with documentation and tests. The module is only used internally by `std`, nothing is exported externally. Code like this is exactly what the `sys_common` module is for, so this PR moves it there.
2021-05-20Not implement `os::unix::fs::chroot` for `vxworks`Christiaan Dirkx-1/+1
2021-05-20Add `ExitStatusError` for `vxworks`Christiaan Dirkx-3/+29
2021-05-19Windows implementation of `fs::try_exists`Chris Denton-1/+30
2021-05-19Move the implementation of `Path::exists` to `sys_common::fs` so platforms ↵Chris Denton-3/+8
can specialize it Windows implementation of `fs::try_exists`
2021-05-19Rename `rterr` to `rtprintpanic`Christiaan Dirkx-2/+2
2021-05-19Replace `sys_common::util::report_overflow` with `rterr!`Christiaan Dirkx-5/+10
2021-05-18Auto merge of #82973 - ijackson:exitstatuserror, r=yaahcbors-10/+94
Provide ExitStatusError Closes #73125 In MR #81452 "Add #[must_use] to [...] process::ExitStatus" we concluded that the existing arrangements in are too awkward so adding that `#[must_use]` is blocked on improving the ergonomics. I wrote a mini-RFC-style discusion of the approach in https://github.com/rust-lang/rust/issues/73125#issuecomment-771092741
2021-05-15Auto merge of #81858 - ijackson:fork-no-unwind, r=m-ou-sebors-0/+28
Do not allocate or unwind after fork ### Objective scenarios * Make (simple) panics safe in `Command::pre_exec_hook`, including most `panic!` calls, `Option::unwrap`, and array bounds check failures. * Make it possible to `libc::fork` and then safely panic in the child (needed for the above, but this requirement means exposing the new raw hook API which the `Command` implementation needs). * In singlethreaded programs, where panic in `pre_exec_hook` is already memory-safe, prevent the double-unwinding malfunction #79740. I think we want to make panic after fork safe even though the post-fork child environment is only experienced by users of `unsafe`, beause the subset of Rust in which any panic is UB is really far too hazardous and unnatural. #### Approach * Provide a way for a program to, at runtime, switch to having panics abort. This makes it possible to panic without making *any* heap allocations, which is needed because on some platforms malloc is UB in a child forked from a multithreaded program (see https://github.com/rust-lang/rust/pull/80263#issuecomment-774272370, and maybe also the SuS [spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html)). * Make that change in the child spawned by `Command`. * Document the rules comprehensively enough that a programmer has a fighting chance of writing correct code. * Test that this all works as expected (and in particular, that there aren't any heap allocations we missed) Fixes #79740 #### Rejected (or previously attempted) approaches * Change the panic machinery to be able to unwind without allocating, at least when the payload and message are both `'static`. This seems like it would be even more subtle. Also that is a potentially-hot path which I don't want to mess with. * Change the existing panic hook mechanism to not convert the message to a `String` before calling the hook. This would be a surprising change for existing code and would not be detected by the type system. * Provide a `raw_panic_hook` function to intercept panics in a way that doesn't allocate. (That was an earlier version of this MR.) ### History This MR could be considered a v2 of #80263. Thanks to everyone who commented there. In particular, thanks to `@m-ou-se,` `@Mark-Simulacrum` and `@hyd-dev.` (Tagging you since I think you might be interested in this new MR.) Compared to #80263, this MR has very substantial changes and additions. Additionally, I have recently (2021-04-20) completely revised this series following very helpful comments from `@m-ou-se.` r? `@m-ou-se`
2021-05-14Move `std::memchr` to `sys_common`Christiaan Dirkx-2/+2
2021-05-13Add support for const operands and options to global_asm!Amanieu d'Antras-1/+1
On x86, the default syntax is also switched to Intel to match asm!
2021-05-13Tolerate SIGTRAP for panic abort after panic::always_abortIan Jackson-1/+1
Some platforma (eg ARM64) apparently generate SIGTRAP for panic abort! See eg https://github.com/rust-lang/rust/pull/81858#issuecomment-840702765 This is probably a bug, but we don't want to entangle this MR with it. When it's fixed, this commit should be reverted. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-12Provide ExitStatusErrorIan Jackson-10/+92
Closes #73125 This is in pursuance of Issue #73127 Consider adding #[must_use] to std::process::ExitStatus In MR #81452 Add #[must_use] to [...] process::ExitStatus we concluded that the existing arrangements in are too awkward so adding that #[must_use] is blocked on improving the ergonomics. I wrote a mini-RFC-style discusion of the approach in https://github.com/rust-lang/rust/issues/73125#issuecomment-771092741 Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-10windows: provide NonZeroDWORDIan Jackson-0/+2
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-07panic/fork test: Do not run on emscriptenIan Jackson-0/+1
fork fails there. The failure message is confusing: so c.status() returns an Err, the closure panics, and the test thinks the panic was propagated from inside the child. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2021-05-07Rollup merge of #85030 - jethrogb:jb/sgx-rearrange-files, r=nagisaDylan DPC-6/+7
Rearrange SGX split module files In #75979 several inlined modules were split out into multiple files. This PR keeps the multiple files but moves a few things around to organize things in a coherent way.
2021-05-07Rollup merge of #85029 - jethrogb:jb/sgx-movable-mutex, r=m-ou-seDylan DPC-1/+1
SGX mutex is movable r? ``@m-ou-se``
2021-05-07Rollup merge of #84655 - CDirkx:wasm, r=m-ou-seDylan DPC-65/+14
Cleanup of `wasm` Some more cleanup of `sys`, this time `wasm` - Reuse `unsupported::args` (functionally equivalent implementation, just an empty iterator). - Split out `atomics` implementation of `wasm::thread`, the non-`atomics` implementation is reused from `unsupported`. - Move all of the `atomics` code to a separate directory `wasm/atomics`. ````@rustbot```` label: +T-libs-impl r? ````@m-ou-se````
2021-05-07Rearrange SGX split module filesJethro Beekman-6/+7
In #75979 several inlined modules were split out into multiple files. This PR keeps the multiple files but moves a few things around to organize things in a coherent way.
2021-05-07SGX mutex is movableJethro Beekman-1/+1
2021-05-07panic ui test: Provide comprehensive test for panic after forkIan Jackson-0/+3
This tests that we can indeed safely panic after fork, both a raw libc::fork and in a Command pre_exec hook. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2021-05-07panic tests: Command: Test that we do not unwind past forkIan Jackson-0/+23
This is safe (does not involve heap allocation) but we don't yet have a test to ensure that stays true. That will come in a moment. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2021-05-07panic/fork: Command: Do not unwind after fork() in childIan Jackson-0/+1
Unwinding after fork() in the child is UB on some platforms, because on those (including musl) malloc can be UB in the child of a multithreaded program, and unwinding must box for the payload. Even if it's safe, unwinding past fork() in the child causes whatever traps the unwind to return twice. This is very strange and clearly not desirable. With the default behaviour of the thread library, this can even result in a panic in the child being transformed into zero exit status (ie, success) as seen in the parent! Fixes #79740. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-07Rollup merge of #84409 - mzohreva:mz/tls-dtors-before-join, r=jethrogbDylan DPC-10/+65
Ensure TLS destructors run before thread joins in SGX The excellent test is from ```@jethrogb``` For context see: https://github.com/rust-lang/rust/pull/83416#discussion_r617282907
2021-05-06Rollup merge of #84712 - joshtriplett:simplify-chdir, r=yaahcDylan DPC-5/+3
Simplify chdir implementation and minimize unsafe block
2021-05-06Use the proper import library namesChris Denton-168/+167
2021-05-06Add `#[link]` attributes to dll importsChris Denton-0/+3
This avoids using jmp stubs when calling functions exported from a dll.
2021-05-03Allow documenting on `hermit`Christiaan Dirkx-1/+0
2021-05-03Move `std::sys::sgx::ext` to `std::os::fortanix_sgx`Christiaan Dirkx-267/+0
2021-05-03Move `std::sys::wasi::ext` to `std::os::wasi`Christiaan Dirkx-813/+0
2021-05-03Move `std::sys::unix::ext` to `std::os::unix`Christiaan Dirkx-5390/+0
2021-05-03Move `std::sys::windows::ext` to `std::os::windows`Christiaan Dirkx-1155/+3
2021-05-03Move `std::sys::hermit::ext` to `std::os::hermit`Christiaan Dirkx-53/+0
2021-05-03Cleanup `std::os`Christiaan Dirkx-35/+23
2021-05-03Auto merge of #84842 - blkerby:null_lowercase, r=joshtriplettbors-5/+5
Replace 'NULL' with 'null' This replaces occurrences of "NULL" with "null" in docs, comments, and compiler error/lint messages. This is for the sake of consistency, as the lowercase "null" is already the dominant form in Rust. The all-caps NULL looks like the C macro (or SQL keyword), which seems out of place in a Rust context, given that NULL does not exist in the Rust language or standard library (instead having [`ptr::null()`](https://doc.rust-lang.org/stable/std/ptr/fn.null.html)).
2021-05-02Change 'NULL' to 'null'Brent Kerby-5/+5
2021-05-02Use ErrorKind::OutOfMemory in unix, windows, and wasiKornel-0/+5
2021-05-01Auto merge of #84658 - Amanieu:reserved_regs, r=petrochenkovbors-2/+8
Be stricter about rejecting LLVM reserved registers in asm! LLVM will silently produce incorrect code if these registers are used as operands. cc `@rust-lang/wg-inline-asm`
2021-05-01Reserve x18 on AArch64 and un-reserve x16Amanieu d'Antras-4/+4
2021-04-30Avoid using rbx in SGX inline assembly since it is reservedAmanieu d'Antras-2/+8
2021-04-30Auto merge of #84716 - joshtriplett:chroot, r=dtolnaybors-0/+33
Add std::os::unix::fs::chroot to change the root directory of the current process This is a straightforward wrapper that uses the existing helpers for C string handling and errno handling. Having this available is convenient for UNIX utility programs written in Rust, and avoids having to call the unsafe `libc::chroot` directly and handle errors manually, in a program that may otherwise be entirely safe code.
2021-04-30Auto merge of #84522 - CDirkx:cmath, r=yaahcbors-118/+34
Reuse `sys::unix::cmath` on other platforms Reuse `sys::unix::cmath` on all non-`windows` platforms. `unix` is chosen as the canonical location instead of `unsupported` or `common` because `unsupported` doesn't make sense semantically and `common` is reserved for code that is supported on all platforms. Also `unix` is already the home of some non-`windows` code that is technically not exclusive to `unix` like `unix::path`.
2021-04-30Add std::os::unix::fs::chroot to change the root directory of the current ↵Josh Triplett-0/+33
process This is a straightforward wrapper that uses the existing helpers for C string handling and errno handling. Having this available is convenient for UNIX utility programs written in Rust, and avoids having to call the unsafe `libc::chroot` directly and handle errors manually, in a program that may otherwise be entirely safe code.