| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Initial implementation of anonymous_pipe API
ACP completed in rust-lang/libs-team#375
Tracking issue: #127154
try-job: x86_64-msvc
try-job: i686-mingw
|
|
At some point it seems `SystemTime::new` changed from returning `SystemTime` to `io::Result<SystemTime>`. This seems to have been addressed on other platforms, but was never changed for AIX.
This was caught by running
```
python3 x.py build --host x86_64-unknown-linux-gnu --target powerpc64-ibm-aix
```
|
|
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>
|
|
can set the stack size using RUST_MIN_STACK, with min size of libc::PTHREAD_STACK_MIN(4kib)
|
|
|
|
|
|
|
|
|
|
lchown for vxworks
|
|
|
|
In so doing, move the forbid up to the top of personality::dwarf
|
|
ian-h-chamberlain:fix/horizon-warnings-unsafe-in-unsafe, r=tgross35
Clean up warnings + `unsafe_op_in_unsafe_fn` when building std for armv6k-nintendo-3ds
See #127747
ping `@AzureMarker` `@Meziu`
I could only find one instance needing an extra `unsafe` that was not also shared with many other `unix` targets (presumably these will get covered in larger sweeping changes, I didn't want to introduce churn that would potentially conflict with those). The one codepath I found is shared with `vita` however, so also pinging `@nikarh` `@pheki` `@zetanumbers` just to make sure they're aware of this change.
Also removed one unused import from `process_unsupported` which should simply fix the warning for any target that uses it.
|
|
Deal with invalid UTF-8 from `gai_strerror`
When the system is using a non-UTF-8 locale, the value will indeed not be UTF-8. That sucks for everyone involved, but is no reason for panic. We can "handle" this gracefully by just using from lossy, replacing the invalid UTF-8 with � and keeping the accidentally valid UTF-8. Good luck when debugging, but at least it's not a crash.
We already do this for `strerror_r`.
fixes #127563
|
|
Also fix one instance of unsafe_op_in_unsafe_fn that's specific to
horizon + vita - most others should be common with other code.
|
|
When the system is using a non-UTF-8 locale, the value will indeed not
be UTF-8. That sucks for everyone involved, but is no reason for panic.
We can "handle" this gracefully by just using from lossy, replacing the
invalid UTF-8 with the ? and keeping the accidentally valid UTF-8.
Good luck when debugging, but at least it's not a crash.
We already do this for `strerror_r`.
|
|
|
|
Remove _tls_used hack
All the MSVC targets use `target_thread_locals` (see the [base spec](https://github.com/rust-lang/rust/blob/1afc5fd042f7583b9668dd62be98325487483d1c/compiler/rustc_target/src/spec/base/windows_msvc.rs#L34)) so this hack is no longer needed. The compiler will ensure that thread locals work properly.
|
|
Windows: move BSD socket shims to netc
On Windows we need to alter a few types so that they can be used in the cross-platform socket code. Currently these alterations are spread throughout the `c` module with some more in the `netc` module.
Let's gather all our BSD compatibility shims in the `netc` module so it's all in one place and easier to discover.
|
|
|
|
r=Amanieu
kmc-solid: `#![forbid(unsafe_op_in_unsafe_fn)]`
The path logic _should_ handle the forbiddance in the itron sources correctly, despite them being an "out-of-line" module.
|
|
r=joboet
unix: document unsafety for std `sig{action,altstack}`
I found many surprising elements here while trying to wrap a measly 5 functions with `unsafe`. I would rather not "just" mindlessly wrap this code with `unsafe { }`, so I decided to document it properly.
On Unix, this code covers the "create and setup signal handler" part of the stack overflow code, and serves as the primary safety boundary for the signal handler. It is rarely audited, very gnarly, and worth extra attention. It calls other unsafe functions defined in this module, but "can we correctly map the right memory, or find the right address ranges?" are separate questions, and get increasingly platform-specific. The question here is the more general "are we doing everything in the correct order, and setting up the handler in the correct way?"
As part of this audit, I noticed that we do some peculiar things that we should probably refrain from. However, I avoided making changes that I deemed might have a different final result in Rust programs. I did, however, reorder some events so that the signal handler is installed _after_ we install the alternate stack. We do not run much code between these events, but it is probably best if the timespan between the handler being available and the new stack being installed is 0 nanoseconds.
|
|
|
|
Add Process support for UEFI
UEFI does not have an actual process. However, it does provide methods to launch and execute another UEFI image. Having process support is important since it is possible to run rust test suit using `Command::output` and is the first step towards being able to run it for UEFI.
Here is an overview of how the support is implemented.
- We create a copy of the SystemTable. This is required since at least OVMF seems to crash if the original system table is modified.
- Stdout and Stderr pipe works by registering a new `simple_text_output` Protocol and pointing the child system table to use those.
- `Stdio::Inherit` just points the console to the current running image console which seems to work with even 3 levels of process.
- `spawn` is left unimplemented since it does not make sense for UEFI architecture. Additionally, since https://github.com/rust-lang/rust/pull/105458 was merged, the `spawn` and `output` implementations are completely independent.
|
|
|
|
|
|
Feat. adding ext that returns change_time
Addresses #112327
|
|
- Update system table crc32
- Fix unsound use of Box
- Free exit data
- Code improvements
- Introduce OwnedTable
- Update r-efi to latest version
- Use extended_varargs_abi_support for
install_multiple_protocol_interfaces and
uninstall_multiple_protocol_interfaces
- Fix comments
- Stub out args implementation
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Also fix stdio inherit
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Only tested in 2 levels right now. Need args support for 3 levels
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Implement stderr support in similar fashion.
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Use a custom simple_text_output protocol to capture output.
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>
|
|
Note that current_guard is probably not unsafe for future work.
|
|
Editorialize on the wisdom of this as we do.
|
|
This is technically "not necessary", as we will "just" segfault instead
if we e.g. arrive inside the handler fn with the null altstack. However,
it seems incorrect to go about this hoping that segfaulting is okay,
seeing as how our purpose here is to mitigate stack overflow problems.
Make sure NEED_ALTSTACK syncs with PAGE_SIZE when we do.
Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>
|
|
sometimes a safety comment is a prayer.
avoid fuzzy provenance casts after deref.
Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>
|
|
workingjubilee:actually-break-up-big-ass-stack-overflow-fn, r=joboet
unix: break `stack_overflow::install_main_guard` into smaller fn
This was one big deeply-indented function for no reason. This made it hard to reason about the boundaries of its safety. Or just, y'know, read. Simplify it by splitting it into platform-specific functions, but which are still asked to keep compiling (a desirable property, since all of these OS use a similar API).
This is mostly a whitespace change, so I suggest reviewing it only after setting Files changed -> (the options gear) -> [x] Hide whitespace as that will make it easier to see how the code was actually broken up instead of raw line diffs.
|
|
|
|
Windows: Use futex implementation for `Once`
Keep the queue implementation for win7.
Inspired by PR #121956
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
|
|
Prevent double reference in generic futex
In the Windows futex implementation we were a little lax at allowing references to references (i.e. `&&`) which can lead to deadlocks due to reading the wrong memory address. This uses a trait to tighten the constraints and ensure this doesn't happen.
r? libs
|
|
Make more Windows functions `#![deny(unsafe_op_in_unsafe_fn)]`
As part of #127747, I've evaluated some more Windows functions and added `unsafe` blocks where necessary. Some are just trivial wrappers that "inherit" the full unsafety of their function, but for others I've added some safety comments. A few functions weren't actually unsafe at all. I think they were just using `unsafe fn` to avoid an `unsafe {}` block.
I'm not touching `c.rs` yet because that is partially being addressed by another PR and also I have plans to further reduce the number of wrapper functions we have in there.
r? libs
|
|
|
|
This just was a mess.
|
|
This function is purely informative, answering where a stack starts.
This is a safe operation, even if an answer requires unsafe code,
and even if the result is some unsafe code decides to trust the answer.
It also doesn't need to fetch the PAGE_SIZE when its caller just did so!
Let's complicate its signature and in doing so simplify its operation.
This allows sprinkling around #[forbid(unsafe_op_in_unsafe_fn)]
|
|
|
|
|
