about summary refs log tree commit diff
path: root/library/std/src/sys/pal/sgx
AgeCommit message (Collapse)AuthorLines
2025-09-12Revert "Constify SystemTime methods"Ralf Jung-11/+4
This reverts commit 7ce620dd7c6fc3371290b40a1ea28146f0d37031. The const-hacks introduces bugs, and they make the code harder to maintain. Let's wait until we can constify these functions without changing their implementation.
2025-09-10std: move `thread` into `sys`joboet-2/+1
2025-09-08std: move `thread` into `sys` (rename only)joboet-158/+0
2025-08-26remove deprecated Error::description in implsMarijn Schouten-10/+3
2025-08-12Constify SystemTime methodsltdk-4/+11
2025-08-06Print thread ID in panic message if thread name is unknownTrevor Gross-1/+5
`panic!` does not print any identifying information for threads that are unnamed. However, in many cases, the thread ID can be determined. This changes the panic message from something like this: thread '<unnamed>' panicked at src/main.rs:3:5: explicit panic To something like this: thread '<unnamed>' (0xff9bf) panicked at src/main.rs:3:5: explicit panic Stack overflow messages are updated as well. This change applies to both named and unnamed threads. The ID printed is the OS integer thread ID rather than the Rust thread ID, which should also be what debuggers print.
2025-07-29Rollup merge of #144500 - joboet:thread-name-stack-overflow, r=ChrisDentonStuart Cook-1/+5
thread name in stack overflow message Fixes rust-lang/rust#144481, which is caused by the thread name not being initialised yet when setting up the stack overflow information. Unfortunately, the stack overflow UI test did not test for the correct thread name being present, and testing this separately didn't occur to me when writing https://github.com/rust-lang/rust/pull/140628. This PR contains the smallest possible fix I could think of: passing the thread name explicitly to the platform thread creation function. In the future I'd very much like to explore some possibilities around merging the thread packet and thread handle into one structure and using that in the platform code instead – but that's best left for another PR. This PR also amends the stack overflow test to check for thread names, so we don't run into this again. ``@rustbot`` label +beta-nominated
2025-07-28thread name in stack overflow messagejoboet-1/+5
2025-07-26Rollup merge of #143272 - tgross35:bump-fortanix, r=jhpratt,jethrogbTrevor Gross-1/+1
Upgrade the `fortanix-sgx-abi` dependency 0.6.1 removes the `compiler-builtins` dependency, part of RUST-142265. The breaking change from 0.5 to 0.6 is for an update to the `insecure_time` API [1]. I validated that `./x c library --target x86_64-fortanix-unknown-sgx` completes successfully with this change. Link: https://github.com/fortanix/rust-sgx/commit/a34e9767f37d6585c18bdbd31cddcadc56670d57 [1]
2025-07-13Attempt to fix up SGX for random API updatesJosh Triplett-2/+2
2025-07-06sleep_until: use clock_nanosleep where possibledvdsk-1/+9
Using clock nanosleep leads to more accurate sleep times on platforms where it is supported. To enable using clock_nanosleep this makes `sleep_until` platform specific. That unfortunatly requires identical placeholder implementations for the other platforms (windows/mac/wasm etc). we will land platform specific implementations for those later. See the `sleep_until` tracking issue. This requires an accessors for the Instant type. As that accessor is only used on the platforms that have clock_nanosleep it is marked as allow_unused. 32bit time_t targets do not use clock_nanosleep atm, they instead rely on the same placeholder as the other platforms. We could make them use clock_nanosleep too in the future using `__clock_nanosleep_time64`. __clock_nanosleep_time64 is documented at: https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html
2025-07-01Upgrade the `fortanix-sgx-abi` dependencyTrevor Gross-1/+1
0.6.1 removes the `compiler-builtins` dependency, part of RUST-142265. The breaking change from 0.5 to 0.6 is for an update to the `insecure_time` API [1]. I validated that `./x c library --target x86_64-fortanix-unknown-sgx` completes successfully with this change. Link: https://github.com/fortanix/rust-sgx/commit/a34e9767f37d6585c18bdbd31cddcadc56670d57 [1]
2025-05-15deduplicate abort implementationsjoboet-2/+5
Currently, the code for process aborts is duplicated across `panic_abort` and `std`. This PR uses `#[rustc_std_internal_symbol]` to make the `std` implementation available to `panic_abort` via the linker, thereby deduplicating the code.
2025-04-28Auto merge of #123239 - Urgau:dangerous_implicit_autorefs, ↵bors-1/+1
r=jdonszelmann,traviscross Implement a lint for implicit autoref of raw pointer dereference - take 2 *[t-lang nomination comment](https://github.com/rust-lang/rust/pull/123239#issuecomment-2727551097)* This PR aims at implementing a lint for implicit autoref of raw pointer dereference, it is based on #103735 with suggestion and improvements from https://github.com/rust-lang/rust/pull/103735#issuecomment-1370420305. The goal is to catch cases like this, where the user probably doesn't realise it just created a reference. ```rust pub struct Test { data: [u8], } pub fn test_len(t: *const Test) -> usize { unsafe { (*t).data.len() } // this calls <[T]>::len(&self) } ``` Since #103735 already went 2 times through T-lang, where they T-lang ended-up asking for a more restricted version (which is what this PR does), I would prefer this PR to be reviewed first before re-nominating it for T-lang. ---- Compared to the PR it is as based on, this PR adds 3 restrictions on the outer most expression, which must either be: 1. A deref followed by any non-deref place projection (that intermediate deref will typically be auto-inserted) 2. A method call annotated with `#[rustc_no_implicit_refs]`. 3. A deref followed by a `addr_of!` or `addr_of_mut!`. See bottom of post for details. There are several points that are not 100% clear to me when implementing the modifications: - ~~"4. Any number of automatically inserted deref/derefmut calls." I as never able to trigger this. Am I missing something?~~ Fixed - Are "index" and "field" enough? ---- cc `@JakobDegen` `@WaffleLapkin` r? `@RalfJung` try-job: dist-various-1 try-job: dist-various-2
2025-04-27Fix SGX library code implicit auto-refUrgau-1/+1
2025-04-27use generic Atomic type where possibleChristopher Durham-16/+12
in core/alloc/std only for now, and ignoring test files Co-authored-by: Pavel Grigorenko <GrigorenkoPV@ya.ru>
2025-04-21Move `sys::pal::os::Env` into `sys::env`Thalia Archibald-99/+1
Although `Env` (as `Vars`), `Args`, path functions, and OS constants are publicly exposed via `std::env`, their implementations are each self-contained. Keep them separate in `std::sys` and make a new module, `sys::env`, for `Env`.
2025-04-21Rollup merge of #139795 - jethrogb:jb/sgx-linkage-comments, r=joboetChris Denton-5/+10
Clarify why SGX code specifies linkage/symbol names for certain statics Specifying linkage/symbol name is solely to ensure a single instance between the `std` crate and its unit tests. Also update the symbol names as items have moved around a bit. The actual name isn't that important, it just needs to be unique. But for debugging it can be useful for it to point to the right place.
2025-04-18Combine env consts into std::sys::env_constsThalia Archibald-10/+0
2025-04-14Clarify why SGX code specifies linkage/symbol names for certain staticsJethro Beekman-5/+10
Also update the symbol names as items have moved around a bit. The actual name isn't that important, it just needs to be unique. But for debugging it can be useful for it to point to the right place.
2025-04-12Move args into std::sysThalia Archibald-61/+1
2025-04-04Move fd into sysThalia Archibald-86/+0
2025-03-22std: move process implementations to `sys`joboet-2/+0
As per #117276, this moves the implementations of `Process` and friends out of the `pal` module and into the `sys` module, removing quite a lot of error-prone `#[path]` imports in the process (hah, get it ;-)). I've also made the `zircon` module a dedicated submodule of `pal::unix`, hopefully we can move some other definitions there as well (they are currently quite a lot of duplications in `sys`). Also, the `ensure_no_nuls` function on Windows now lives in `sys::pal::windows` – it's not specific to processes and shared by the argument implementation.
2025-03-11Fix `UserRef<[T]>::copy_to_enclave_vec`Thalia Archibald-13/+6
It reinterprets uninitialized memory as initialized and does not drop existing elements of the Vec. Fix that. Additionally, make it more general by appending, instead of overwriting existing elements, and rename it to `append_to_enclave_vec`. A caller can simply call `.clear()` before, for the old behavior.
2025-03-10Implement read_buf and vectored read/write for SGX stdioThalia Archibald-2/+17
2025-03-10Copy from userspace to MaybeUninitJethro Beekman-3/+42
Co-authored-by: Thalia Archibald <thalia@archibald.dev>
2025-03-09std: move stdio to `sys`joboet-90/+13
As per #117276, this moves the platform definitions of `Stdout` and friends into `sys`. This PR also unifies the UNIX and Hermit implementations and moves the `__rust_print_err` function needed by libunwind on SGX into the dedicated module for such helper functions.
2025-03-08Move fs into sysThalia Archibald-2/+0
2025-03-06library: Use size_of from the prelude instead of importedThalia Archibald-23/+19
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the prelude instead of importing or qualifying them. These functions were added to all preludes in Rust 1.80.
2025-02-13std: Apply unsafe_attr_outside_unsafeEric Huss-14/+14
2025-02-09Mark extern blocks as unsafeMichael Goulet-7/+7
2025-02-07std: get rid of `sys_common::io`joboet-1/+1
2025-02-07std: move `io` module out of `pal`joboet-2/+0
2025-02-02std: move network code into `sys`joboet-537/+0
As per #117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support #135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules. I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
2024-12-17Use field init shorthand where possibleJosh Triplett-1/+1
Field init shorthand allows writing initializers like `tcx: tcx` as `tcx`. The compiler already uses it extensively. Fix the last few places where it isn't yet used.
2024-11-26std: update internal uses of `io::const_error!`joboet-2/+2
2024-10-08Change a few `&Option<T>` into `Option<&T>`Yuri Astrakhan-7/+7
2024-09-23std: implement the `random` featurejoboet-20/+2
Implements the ACP https://github.com/rust-lang/libs-team/issues/393.
2024-09-22Reformat using the new identifier sorting from rustfmtMichael Goulet-4/+4
2024-08-27std: move allocators to `sys`joboet-99/+0
2024-08-07Rollup merge of #125048 - dingxiangfei2009:stable-deref, r=amanieuMatthias Krüger-0/+4
PinCoerceUnsized trait into core cc ``@Darksonn`` ``@wedsonaf`` ``@ojeda`` This is a PR to introduce a `PinCoerceUnsized` trait in order to make trait impls generated by the proc-macro `#[derive(SmartPointer)]`, proposed by [RFC](https://github.com/rust-lang/rfcs/blob/e17e19ac7ad1c8ccad55d4babfaee1aa107d1da5/text/3621-derive-smart-pointer.md#pincoerceunsized-1), sound. There you may find explanation, justification and discussion about the alternatives. Note that we do not seek stabilization of this `PinCoerceUnsized` trait in the near future. The stabilisation of this trait does not block the eventual stabilization process of the `#[derive(SmartPointer)]` macro. Ideally, use of `DerefPure` is more preferrable except this will actually constitute a breaking change. `PinCoerceUnsized` emerges as a solution to the said soundness hole while avoiding the breaking change. More details on the `DerefPure` option have been described in this [section](https://github.com/rust-lang/rfcs/blob/e17e19ac7ad1c8ccad55d4babfaee1aa107d1da5/text/3621-derive-smart-pointer.md#derefpure) of the RFC linked above. Earlier discussion can be found in this [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Pin.20and.20soundness.20of.20unsizing.20coercions) and [rust-for-linux thread](https://rust-lang.zulipchat.com/#narrow/stream/425075-rust-for-linux/topic/.23.5Bderive.28SmartPointer.29.5D.20and.20pin.20unsoundness.20rfc.233621). try-job: dist-various-2
2024-07-31PinCoerceUnsized trait into coreXiangfei Ding-0/+4
2024-07-30Insert some blank lines.Nicholas Nethercote-0/+1
After things that are immediately followed by a `use` declaration and look like they might apply to that `use` item but actually don't.
2024-07-29Reformat `use` declarations.Nicholas Nethercote-38/+26
The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.
2024-07-26Fix doc nitsJohn Arundel-8/+10
Many tiny changes to stdlib doc comments to make them consistent (for example "Returns foo", rather than "Return foo", per RFC1574), adding missing periods, paragraph breaks, backticks for monospace style, and other minor nits. https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text
2024-07-15lib: replace some `mem::forget`'s with `ManuallyDrop`Pavel Grigorenko-13/+8
2024-06-15std: refactor the TLS implementationjoboet-24/+0
As discovered by Mara in #110897, our TLS implementation is a total mess. In the past months, I have simplified the actual macros and their expansions, but the majority of the complexity comes from the platform-specific support code needed to create keys and register destructors. In keeping with #117276, I have therefore moved all of the `thread_local_key`/`thread_local_dtor` modules to the `thread_local` module in `sys` and merged them into a new structure, so that future porters of `std` can simply mix-and-match the existing code instead of having to copy the same (bad) implementation everywhere. The new structure should become obvious when looking at `sys/thread_local/mod.rs`. Unfortunately, the documentation changes associated with the refactoring have made this PR rather large. That said, this contains no functional changes except for two small ones: * the key-based destructor fallback now, by virtue of sharing the implementation used by macOS and others, stores its list in a `#[thread_local]` static instead of in the key, eliminating one indirection layer and drastically simplifying its code. * I've switched over ZKVM (tier 3) to use the same implementation as WebAssembly, as the implementation was just a way worse version of that Please let me know if I can make this easier to review! I know these large PRs aren't optimal, but I couldn't think of any good intermediate steps. @rustbot label +A-thread-locals
2024-06-05Rollup merge of #125800 - fortanix:raoul/rte-99-fix_mut_static_task_queue, ↵Matthias Krüger-12/+6
r=jethrogb Fix `mut` static task queue in SGX target [PR 125046](https://github.com/rust-lang/rust/pull/125046) prevents mutable references to statics with `#[linkage]`. Such a construct was used with the tests for the `x86_64-fortanix-unknown-sgx` target. This PR fixes this and cleans up code a bit in 5 steps. Each step passes CI: - The `mut` static is removed, and `Task` explicitly implements `Send` - Renaming of the `task_queue::lock` function - Pass function for `Thread` as `Send` to `Thread::imp` and update when `Packet<'scope, T>` implements `Sync` - Storing `Task::p` as a type that implements `Send` - Letting the compiler auto implement `Send` for `Task` cc: ``@jethrogb``
2024-06-04Let compiler auto impl `Send` for `Task`Raoul Strackx-2/+0
2024-06-04Store `Task::p` as `dyn FnOnce() + Send`Raoul Strackx-3/+3