| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Migrate the standard library from using the external `cfg_if` crate to
using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from
`library/std/Cargo.toml`, because while the standard library itself no
longer uses `cfg_if`, it also incorporates the `backtrace` crate, which
does.
Migration assisted by the following vim command (after selecting the
full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This
prompts for confirmation on the `} else {` since that can also appear
inside one of the arms. This also requires manual intervention to handle
any multi-line conditions.
|
|
Windows: Replace `GetThreadId`+`GetCurrentThread` with `GetCurrentThreadId`
Reference: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getcurrentthreadid
|
|
Reference: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getcurrentthreadid
|
|
Currently, when setting the thread stack size fails, it would be rounded
up to the nearest multiple of the page size and the code asserts that
the next call to pthread_attr_setstacksize succeeds.
This may be true for glibc, but it isn't true for musl, which not only
enforces a minimum stack size, but also a maximum stack size of
usize::MAX / 4 - PTHREAD_STACK_MIN [1], triggering the assert rather
than erroring gracefully.
There isn't any way to handle this properly other than bailing out and
letting the user know it didn't succeed.
[1]: https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_attr_setstacksize.c#n5
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
Add `cast_init` and `cast_uninit` methods for pointers
ACP: rust-lang/libs-team#627
Tracking issue: rust-lang/rust#145036
This includes an incredibly low-effort search to find uses that could be switched to using these methods. I only searched for `cast::<\w>` and `cast::<MaybeUninit` because there would otherwise be way too much to look through, and I also didn't modify anything inside submodules/subtrees.
|
|
|
|
|
|
Add tests to ensure that extream system times are still representable.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
Use a time representation with 1900-01-01-00:00:00 at timezone -1440 min as
anchor. This is the earliest time supported in UEFI.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
std: sys: io: io_slice: Add UEFI types
UEFI networking APIs do support vectored read/write. While the types for UDP4, UDP6, TCP4 and TCP6 are defined separately, they are essentially the same C struct. So we can map IoSlice and IoSliceMut to have the same binary representation.
Since all UEFI networking types for read/write are DSTs, `IoSlice` and `IoSliceMut` will need to be copied to the end of the transmit/receive structures. So having the same binary representation just allows us to do a single memcpy instead of having to loop and set the DST.
cc ``@nicholasbishop``
|
|
Replace unsafe `security_attributes` function with safe `inherit_handle` alternative
The `security_attributes` function is marked as safe despite taking a raw pointer which will later be used. Fortunately this function is only used internally and only in one place that has been basically the same for a decade now. However, we only ever set one bool so it's easy enough to replace with something that's actually safe.
In the future we might want to expose the ability for users to set security attributes. But that should be properly designed (and safe!).
|
|
The `security_attributes` function is marked as safe despite taking a raw pointer which will later be used. Fortunately this function is only used internally and only in one place that has been basically the same for a decade now.
However, we only ever set one bool so it's easy enough to replace with something that's actually safe.
|
|
|
|
compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled
Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled.
Enabling LSE is the primary motivator for rust-lang/rust#143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE.
r? ```````@tgross35```````
|
|
`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.
|
|
Create a private module to hold the bootstrap code needed enable LSE
at startup on aarch64-*-linux-* targets when rust implements the
intrinsics.
This is a bit more heavyweight than compiler-rt's LSE initialization,
but has the benefit of initializing the aarch64 cpu feature detection
for other uses.
Using the rust initialization code does use some atomic operations,
that's OK. Mixing LSE and non-LSE operations should work while the
update flag propagates.
|
|
UEFI networking APIs do support vectored read/write. While the types for
UDP4, UDP6, TCP4 and TCP6 are defined separately, they are essentially
the same C struct. So we can map IoSlice and IoSliceMut to have the same
binary representation.
Since all UEFI networking types for read/write are DSTs, `IoSlice` and
`IoSliceMut` will need to be copied to the end of the transmit/receive
structures. So having the same binary representation just allows us to
do a single memcpy instead of having to loop and set the DST.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
Currently the Args new function is scope constrained to pub(super) but this stops me from being able to construct Args structs in unit tests.
|
|
`compiler_builtins` shouldn't be called directly. Change the `PartialEq`
implementation for `DevicePathNode` to use slice equality instead, which
will call `memcmp`/`bcmp` via the intrinsic.
|
|
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
|
|
|
|
|
|
If `HOME` is empty, use the fallback instead
This is a minor change in the `home_dir` api. An empty path is never (or should never be) valid so if the `HOME` environment variable is empty then let's use the fallback instead.
r? libs-api
|
|
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]
|
|
Darwin's `read`/`write` syscalls emit `EINVAL` only when `nbyte > INT_MAX`.
The case `nbyte == INT_MAX` is valid, so the subtraction can be removed.
|
|
std: net: uefi: Add support to query connection data
- Use EFI_TCP4_GET_MODE_DATA to be able to query for ttl, nodelay, peer_addr and socket_addr.
- peer_addr is needed for implementation of `accept`.
- cc `````@nicholasbishop`````
- Also a heads up. The UEFI spec seems to be wrong or something for [EFI_TCP4_CONFIG_DATA](https://uefi.org/specs/UEFI/2.11/28_Network_Protocols_TCP_IP_and_Configuration.html#efi-tcp4-protocol-getmodedata). `ControlOption` should be a pointer as seen in [edk2](https://github.com/tianocore/edk2/blob/a1b509c1a453815acbc6c8b0fc5882fd03a6f2c0/MdePkg/Include/Protocol/Tcp4.h#L97).
|
|
- Use EFI_TCP4_GET_MODE_DATA to be able to query for ttl, nodelay,
peer_addr and socket_addr.
- peer_addr is needed for implementation of `accept`.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
On the 32-bit win7 target, we use OS TLS instead of native TLS, due to
issues with how the OS handles alignment. Unfortunately, this caused
issues due to the TLS destructors not running, causing memory leaks
among other problems.
On Windows, to support OS TLS, the TlsAlloc family of function is used
by Rust. This function does not support TLS destructors at all. However,
rust has some code to emulate those destructors, by leveraging the TLS
support functionality found in the MSVC CRT (specifically, in tlssup.c
of the CRT). Specifically, the CRT provides the ability to register
callbacks that are called (among other things) on thread destruction. By
registering our own callback, we can run through a list of registered
destructors functions to execute.
To use this functionality, the user must do two things:
1. They must put the address to their callback in a section between
`.CRT$XLB` and `.CRT$XLY`.
2. They must add a reference to `_tls_used` (or `__tls_used` on x86) to
make sure the TLS support code in tlssup.c isn't garbage collected by
the linker.
Prior to this commit, this second bit wasn't being done properly by the
Rust TLS support code. Instead of adding a reference to _tls_used, it
instead had a reference to its own callback to prevent it from getting
GC'd by the linker. While this is _also_ necessary, not having a
reference on _tls_used made the entire support non-functional.
This commit reworks the code to:
1. Add an unconditional `#[used]` attribute on the CALLBACK, which
should be enough to prevent it from getting GC'd by the linker.
2. Add a reference to `_tls_used`, which should pull the TLS support
code into the Rust programs and not let it be GC'd by the linker.
|
|
UWP: link ntdll functions using raw-dylib
Lazy loading isn't necessary so there's no need for the added complexity and overhead. However, it may be that people using UWP rust libraries don't have the necessary import libraries linked by Visual Studio so this uses raw-dylib, which allows linking to DLL functions without having an import library. This is a somewhat temporary situation as raw-dylib is intended to eventually be the default for all imports. When that happens, this special case can be removed.
Closes rust-lang/rust#143530
|
|
Add experimental `backtrace-trace-only` std feature
This experimentally allows building std with backtrace but without symbolisation. It does not affect stable and requires build-std to use. This doesn't change the backtrace crate itself so relies on the optimizer to remove the unused parts.
Example usage:
```toml
# .cargo/config.toml
[unstable]
build-std = ["core", "alloc", "panic_unwind", "std"]
build-std-features = ["backtrace", "backtrace-trace-only", "panic-unwind"]
```
```toml
# Cargo.toml
[profile.release]
opt-level = 3
lto = "thin"
codegen-units = 1
```
Ideally we should split the backtrace feature into `backtrace-trace` and `backtrace-symbolize` (with the latter dependent on the former) because Cargo features tend to work better when they're positive rather than negative. But I'm keen for this experiment not to break existing users.
cc ``@joshtriplett``
|
|
Updates to random number generation APIs
Updates based on discussions about random number generation.
- Add comment on `RandomSource::fill_bytes` about multiple calls, to allow
efficient implementations for random sources that generate a word at a time.
- Drop the `Random` trait in favor of `Distribution<T>`, which will let people
make calls like random(1..=6), and which allows for future expansion to
non-uniform distributions, as well as floating-point. (For now, this is only
implemented for `RangeFull`, to get the interface in place. Subsequent PRs
will implement it for other range types.)
|
|
Don't call WSACleanup on process exit
This isn't necessary as cleanup will happen when the process exits regardless.
fixes rust-lang/rust#141799
|
|
|
|
|
|
Use zero for initialized Once state
By re-labeling which integer represents which internal state for `Once` we can ensure that the initialized state is the all-zero state. This is beneficial because some CPU architectures (such as Arm) have specialized instructions to specifically branch on non-zero, and checking for the initialized state is by far the most important operation.
As an example, take this:
```rust
use std::sync::atomic::{AtomicU32, Ordering};
const INIT: u32 = 3;
#[inline(never)]
#[cold]
pub fn slow(state: &AtomicU32) {
state.store(INIT, Ordering::Release);
}
pub fn ensure_init(state: &AtomicU32) {
if state.load(Ordering::Acquire) != INIT {
slow(state)
}
}
```
If `INIT` is 3 (as is currently the state for `Once`), we see the following assembly on `aarch64-apple-darwin`:
```asm
example::ensure_init::h332061368366e313:
ldapr w8, [x0]
cmp w8, #3
b.ne LBB1_2
ret
LBB1_2:
b example::slow::ha042bd6a4f33724e
```
By changing the `INIT` state to zero we get the following:
```asm
example::ensure_init::h332061368366e313:
ldapr w8, [x0]
cbnz w8, LBB1_2
ret
LBB1_2:
b example::slow::ha042bd6a4f33724e
```
So this PR saves 1 instruction every time a `LazyLock` gets accessed on platforms such as these.
|
|
|
|
|
|
|
|
std: move NuttX to use arc4random for random number generation
arc4random support in libc merged in https://github.com/rust-lang/libc/pull/4464, so:
* Move `target_os = "nuttx"` from unix_legacy to arc4random section
* This aligns NuttX with other POSIX-compliant systems that support arc4random
* Improves random number generation quality on NuttX by using the system's built-in arc4random implementation instead of legacy fallback methods
NuttX supports arc4random_buf which provides better entropy and security compared to the legacy random number generation methods.
|
|
* Move `target_os = "nuttx"` from unix_legacy to arc4random section
* This aligns NuttX with other POSIX-compliant systems that support arc4random
* Improves random number generation quality on NuttX by using the system's
built-in arc4random implementation instead of legacy fallback methods
NuttX supports arc4random_buf which provides better entropy and security
compared to the legacy random number generation methods.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
|
|
std: sys: net: uefi: tcp4: Add timeout support
- Implement timeout support for read, write and connect.
- A software implementation using Instant.
|
|
rust: library: Add `setsid` method to `CommandExt` trait
Add a setsid method to the CommandExt trait so that callers can create a process in a new session and process group whilst still using the POSIX spawn fast path.
Tracking issue: rust-lang/rust#105376
ACP: https://github.com/rust-lang/libs-team/issues/184
This PR was previously submitted by ``@HarveyHunt`` (whom I marked as Co-Author in the commit message) in rust-lang/rust#105377. However that PR went stale.
I applied the [suggestion](https://github.com/rust-lang/rust/pull/105377/files/231d19fcbfe155b2e85116865adae4253380ff1f#r1893457943) to change the function signature to `fn setsid(&mut self, setsid: bool) -> &mut Command`.
|
|
Add a setsid method to the CommandExt trait so that callers can create
a process in a new session and process group whilst still using the
POSIX spawn fast path.
Co-Authored-By: Harvey Hunt <harveyhunt@fb.com>
|
|
- Implement timeout support for read, write and connect.
- A software implementation using Instant.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
|
|
|
|
Specialize sleep_until implementation for unix (except mac)
related tracking issue: https://github.com/rust-lang/rust/issues/113752
Supersedes https://github.com/rust-lang/rust/pull/118480 for the reasons see: https://github.com/rust-lang/rust/issues/113752#issuecomment-2902594469
Replaces the generic catch all implementation with target_os specific ones for: linux/netbsd/freebsd/android/solaris/illumos etc. Other platforms like wasi, macos/ios/tvos/watchos and windows will follow in later separate PR's (once this is merged).
|
|
The clock_nanosleep support is there to allow code using `sleep_until`
to run under Miri. Therefore the implementation is minimal.
- Only the clocks REALTIME and MONOTONIC are supported. The first is supported simply
because it was trivial to add not because it was needed for sleep_until.
- The only supported flag combinations are no flags or TIMER_ABSTIME only.
If an unsupported flag combination or clock is passed in this throws
unsupported.
|
