about summary refs log tree commit diff
path: root/library/std/src/sys/mod.rs
AgeCommit message (Collapse)AuthorLines
2024-09-25Revert Break into the debugger on panic (129019)Chris Denton-1/+0
2024-09-23std: implement the `random` featurejoboet-0/+1
Implements the ACP https://github.com/rust-lang/libs-team/issues/393.
2024-09-05Break into the debugger (if attached) on panics (Windows, macOS, Linux, FreeBSD)kromych-0/+1
The developer experience for panics is to provide the backtrace and exit the program. When running under debugger, that might be improved by breaking into the debugger once the code panics thus enabling the developer to examine the program state at the exact time when the code panicked. Let the developer catch the panic in the debugger if it is attached. If the debugger is not attached, nothing changes. Providing this feature inside the standard library facilitates better debugging experience. Validated under Windows, Linux, macOS 14.6, and FreeBSD 13.3..14.1.
2024-08-27std: move allocators to `sys`joboet-0/+1
2024-07-30Cleanup sys module to match house styleChris Denton-1/+0
2024-07-23Initial implementation of anonymous_pipeJiahao XU-0/+2
Co-authored-by: Alphyr <47725341+a1phyr@users.noreply.github.com> Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com> Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
2024-07-14std: deny(unsafe_op_in_unsafe_fn) but allow sitesJubilee Young-0/+2
This provides a list of locations to hunt down issues in.
2024-07-07Move/change declaration of `mod exit_guard;`zachs18-1/+1
2024-07-05Move exit guard from sys::common::exit_guard to sys::exit_guard.Zachary S-0/+1
2024-06-16std: move `sys_common::backtrace` to `sys`joboet-0/+1
2024-05-24std: clean up the TLS implementationjoboet-2/+0
2024-03-12std: move `Once` implementations to `sys`joboet-1/+1
2024-02-28std: move thread local implementation to `sys`joboet-0/+3
2024-02-16std: move locks to `sys` on µITRONjoboet-0/+1
2024-02-08std: move path into `sys`joboet-0/+1
2024-01-22std: move cmath into `sys`joboet-1/+3
2024-01-15std: move OS String implementation into `sys`joboet-0/+1
2024-01-13std: move personality implementation out of PALjoboet-0/+2
2024-01-11std: begin moving platform support modules into `pal`joboet-124/+8
2023-12-07add teeos std impl袁浩-0/+3
Signed-off-by: 袁浩 <yuanhao34@huawei.com>
2023-09-22Use RawOsError for UEFIAyush Singh-0/+1
Some changes from this commit will probably be converted to its own PR. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-22Add Minimal Std implementation for UEFIAyush Singh-0/+3
Implemented modules: 1. alloc 2. os_str 3. env 4. math Tracking Issue: https://github.com/rust-lang/rust/issues/100499 API Change Proposal: https://github.com/rust-lang/libs-team/issues/87 This was originally part of https://github.com/rust-lang/rust/pull/100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from @dvdhrm, I have extracted a minimal std implementation to this PR. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-19Auto merge of #104101 - betrusted-io:xous-libstd-initial, r=bjorn3bors-0/+3
Add initial libstd support for Xous This patchset adds some minimal support to the tier-3 target `riscv32imac-unknown-xous-elf`. The following features are supported: * alloc * thread creation and joining * thread sleeping * thread_local * panic_abort * mutex * condvar * stdout Additionally, internal support for the various Xous primitives surrounding IPC have been added as part of the Xous FFI. These may be exposed as part of `std::os::xous::ffi` in the future, however for now they are not public. This represents the minimum viable product. A future patchset will add support for networking and filesystem support.
2023-09-03Move RawOsError defination to sysAyush Singh-0/+2
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
2023-08-22libstd: add xous to libstdSean Cross-0/+3
Add the `xous` target to libstd. Currently this defers everything to the `unsupported` target. Signed-off-by: Sean Cross <sean@xobs.io>
2023-07-10Auto merge of #108796 - devsnek:personality-pal-exception, r=workingjubileebors-0/+1
move personality to sys this moves `personality` to sys, removing another PAL exception
2023-07-09move personality to sysGus Caplan-0/+1
2023-07-09move pal cfgs in f32 and f64 to sysGus Caplan-0/+49
2023-05-09Don't force include Windows goop when documentingChris Denton-25/+0
2023-03-17reviewGus Caplan-2/+2
2023-03-17move default backtrace setting to sysGus Caplan-0/+9
2022-10-03Reduce CString allocations in std as much as possibleAlex Saveau-1/+1
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
2021-11-10Use `target_family = "wasm"`Alex Crichton-1/+1
2021-11-10std: Get the standard library compiling for wasm64Alex Crichton-1/+1
This commit goes through and updates various `#[cfg]` as appropriate to get the wasm64-unknown-unknown target behaving similarly to the wasm32-unknown-unknown target. Most of this is just updating various conditions for `target_arch = "wasm32"` to also account for `target_arch = "wasm64"` where appropriate. This commit also lists `wasm64` as an allow-listed architecture to not have the `restricted_std` feature enabled, enabling experimentation with `-Z build-std` externally. The main goal of this commit is to enable playing around with `wasm64-unknown-unknown` externally via `-Z build-std` in a way that's similar to the `wasm32-unknown-unknown` target. These targets are effectively the same and only differ in their pointer size, but wasm64 is much newer and has much less ecosystem/library support so it'll still take time to get wasm64 fully-fledged.
2021-09-28Add SOLID targetsTomoaki Kawada-0/+3
SOLID[1] is an embedded development platform provided by Kyoto Microcomputer Co., Ltd. This commit introduces a basic Tier 3 support for SOLID. # New Targets The following targets are added: - `aarch64-kmc-solid_asp3` - `armv7a-kmc-solid_asp3-eabi` - `armv7a-kmc-solid_asp3-eabihf` SOLID's target software system can be divided into two parts: an RTOS kernel, which is responsible for threading and synchronization, and Core Services, which provides filesystems, networking, and other things. The RTOS kernel is a μITRON4.0[2][3]-derived kernel based on the open-source TOPPERS RTOS kernels[4]. For uniprocessor systems (more precisely, systems where only one processor core is allocated for SOLID), this will be the TOPPERS/ASP3 kernel. As μITRON is traditionally only specified at the source-code level, the ABI is unique to each implementation, which is why `asp3` is included in the target names. More targets could be added later, as we support other base kernels (there are at least three at the point of writing) and are interested in supporting other processor architectures in the future. # C Compiler Although SOLID provides its own supported C/C++ build toolchain, GNU Arm Embedded Toolchain seems to work for the purpose of building Rust. # Unresolved Questions A μITRON4 kernel can support `Thread::unpark` natively, but it's not used by this commit's implementation because the underlying kernel feature is also used to implement `Condvar`, and it's unclear whether `std` should guarantee that parking tokens are not clobbered by other synchronization primitives. # Unsupported or Unimplemented Features Most features are implemented. The following features are not implemented due to the lack of native support: - `fs::File::{file_attr, truncate, duplicate, set_permissions}` - `fs::{symlink, link, canonicalize}` - Process creation - Command-line arguments Backtrace generation is not really a good fit for embedded targets, so it's intentionally left unimplemented. Unwinding is functional, however. ## Dynamic Linking Dynamic linking is not supported. The target platform supports dynamic linking, but enabling this in Rust causes several problems. - The linker invocation used to build the shared object of `std` is too long for the platform-provided linker to handle. - A linker script with specific requirements is required for the compiled shared object to be actually loadable. As such, we decided to disable dynamic linking for now. Regardless, the users can try to create shared objects by manually invoking the linker. ## Executable Building an executable is not supported as the notion of "executable files" isn't well-defined for these targets. [1] https://solid.kmckk.com/SOLID/ [2] http://ertl.jp/ITRON/SPEC/mitron4-e.html [3] https://en.wikipedia.org/wiki/ITRON_project [4] https://toppers.jp/
2021-05-03Allow documenting on `hermit`Christiaan Dirkx-1/+0
2021-05-03Move `std::sys::wasi::ext` to `std::os::wasi`Christiaan Dirkx-17/+0
2021-05-03Move `std::sys::unix::ext` to `std::os::unix`Christiaan Dirkx-16/+0
2021-05-03Move `std::sys::windows::ext` to `std::os::windows`Christiaan Dirkx-10/+3
2021-05-03Cleanup `std::os`Christiaan Dirkx-35/+23
2021-04-19Move `sys::vxworks` code to `sys::unix`Christiaan Dirkx-4/+1
2021-04-14Move `std::sys_common::alloc` to `std::sys::common`Christiaan Dirkx-0/+2
2021-03-22Rollup merge of #82686 - CDirkx:unix-platform, r=m-ou-seDylan DPC-2/+0
Move `std::sys::unix::platform` to `std::sys::unix::ext` This moves the operating system dependent alias `platform` (`std::os::{linux, android, ...}`) from `std::sys::unix` to `std::sys::unix::ext` (a.k.a. `std::os::unix`), removing the need for compatibility code in `unix_ext` when documenting on another platform. This is also a step in making it possible to properly move `std::sys::unix::ext` to `std::os::unix`, as ideally `std::sys` should not depend on the rest of `std`.
2021-03-02Move `std::sys::unix::platform` to `std::sys::unix::ext`Christiaan Dirkx-2/+0
2021-03-01Add missing stability attributes in libstdGuillaume Gomez-1/+2
2021-02-23Enable API documentation for `std::os::wasi`.Dan Gohman-4/+26
This adds API documentation support for `std::os::wasi` modeled after how `std::os::unix` works, so that WASI can be documented [here] along with the other platforms. [here]: https://doc.rust-lang.org/stable/std/os/index.html Two changes of particular interest: - This changes the `AsRawFd` for `io::Stdin` for WASI to return `libc::STDIN_FILENO` instead of `sys::stdio::Stdin.as_raw_fd()` (and similar for `Stdout` and `Stderr`), which matches how the `unix` version works. `STDIN_FILENO` etc. may not always be explicitly reserved at the WASI level, but as long as we have Rust's `std` and `libc`, I think it's reasonable to guarantee that we'll always use `libc::STDIN_FILENO` for stdin. - This duplicates the `osstr2str` utility function, rather than trying to share it across all the configurations that need it.
2020-11-22Drop support for cloudabi targetsLzu Tao-9/+4
2020-10-11add hermit to the list of omit OSStefan Lankes-0/+1
2020-07-27mv std libs to library/mark-0/+112
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 01:17:50 +0000