std: add platform support for hexagon-unknown-qurt by androm3da · Pull Request #152084 · rust-lang/rust

androm3da · 2026-02-04T04:50:05Z

QuRT is not a unix target but provides POSIX-compatible threading, file I/O, and synchronization APIs. This implementation does not declare unix as a target family. Instead, it explicitly opts into the unix PAL and selects unix-based implementations for individual subsystems where QuRT's POSIX layer is sufficient.

Supported: alloc, threading, mutex, condvar, rwlock, once, thread parking, TLS, file system, file descriptors, stdio, I/O slices, I/O errors, is_terminal, env, paths, time, exit, personality/unwinding, backtrace

Stubbed; returns Err: process spawning, networking, pipes, hostname
Stubbed; returns empty: command-line args
Stubbed; panics: random

Platform modules:

New os::qurt module with platform-specific extensions (ffi, fs, io, raw)

rustbot · 2026-02-04T04:50:10Z

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

androm3da · 2026-02-04T15:14:47Z

This PR depends on a newer version of the libc crate - maybe I'll let this PR hang here for a bit and check back in when it gets released and promoted?

joboet · 2026-02-07T15:21:04Z

This PR depends on a newer version of the libc crate - maybe I'll let this PR hang here for a bit and check back in when it gets released and promoted?

You need libc at 0.2.179, right? You can update libc here – but please keep it in a separate commit.

joboet · 2026-02-07T15:35:05Z

@rustbot author

rustbot · 2026-02-07T15:35:10Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

androm3da · 2026-02-08T18:25:04Z

This PR depends on a newer version of the libc crate - maybe I'll let this PR hang here for a bit and check back in when it gets released and promoted?

You need libc at 0.2.179, right? You can update libc here – but please keep it in a separate commit.

The commit I need - rust-lang/libc@9934c04 is not yet tagged/released. Or rather there is a ctest-* tag but I suspect that doesn't apply/not intended use for that tag. Should I try to execute a tag/release of libc, or just wait for that to happen naturally?

androm3da · 2026-02-17T06:16:27Z

This PR depends on a newer version of the libc crate - maybe I'll let this PR hang here for a bit and check back in when it gets released and promoted?

You need libc at 0.2.179, right? You can update libc here – but please keep it in a separate commit.

The commit I need - rust-lang/libc@9934c04 is not yet tagged/released. Or rather there is a ctest-* tag but I suspect that doesn't apply/not intended use for that tag. Should I try to execute a tag/release of libc, or just wait for that to happen naturally?

Ah - I see now that it appears in 0.2.181 and there's already a PR open for that (#150752). I'll rebase when that lands.

ahmayun · 2026-10-09T15:12:23Z

Hi @joboet

I'm taking over this PR from @androm3da. I believe all your comments on the PR have been addressed and I've resolved the merge conflicts with main. Kindly let me know if more changes are needed.

I've built and tested this for hexagon-unknown-qurt. ~~The build does depend on a minor libc change that is currently an open PR~~ (PR has been merged)

joboet · 2026-10-12T18:06:35Z

@rustbot ready
(I rarely look at things not marked as S-waiting-on-review)

joboet · 2026-10-20T12:04:38Z

+// NOTE: this is not guaranteed to run, for example when Rust code is called externally.
+pub unsafe fn init(argc: isize, argv: *const *const u8, _sigpipe: u8) {
+    stack_overflow::init();
+    unsafe { crate::sys::args::init(argc, argv) };


This is a noop and can be removed...

Suggested change

unsafe { crate::sys::args::init(argc, argv) };

View changes since the review

joboet · 2026-10-20T12:05:21Z

+#[cfg(target_os = "qurt")]
+pub unsafe fn init(_argc: isize, _argv: *const *const u8) {
+    // QuRT goes through the unix PAL's `init`, but has no args to record.
+}
+


... rendering this unnecessary.

Suggested change

#[cfg(target_os = "qurt")]

pub unsafe fn init(_argc: isize, _argv: *const *const u8) {

// QuRT goes through the unix PAL's `init`, but has no args to record.

}

View changes since the review

joboet · 2026-10-20T12:06:57Z

+// SAFETY: must be called only once during runtime initialization.
+// NOTE: this is not guaranteed to run, for example when Rust code is called externally.
+pub unsafe fn init(argc: isize, argv: *const *const u8, _sigpipe: u8) {
+    stack_overflow::init();


And this, too, is redundant.

View changes since the review

joboet · 2026-10-20T12:07:12Z

+#[path = "../unix/stack_overflow.rs"]
+pub mod stack_overflow;


Suggested change

#[path = "../unix/stack_overflow.rs"]

pub mod stack_overflow;

View changes since the review

I decided not to remove this since qurt still reuses some of unix's thread code and removing this will cause an error on this line. I did, however, update the stale path.

joboet · 2026-10-20T12:07:35Z

+#[path = "../unix/thread_parking.rs"]
+pub mod thread_parking;


This is only relevant for NetBSD.

Suggested change

#[path = "../unix/thread_parking.rs"]

pub mod thread_parking;

View changes since the review

joboet · 2026-10-20T12:08:39Z

Thanks, and no worries!

joboet · 2026-10-20T12:09:25Z

Since there is now a dedicated PAL module, the changes here can be undone.

joboet · 2026-10-20T12:10:51Z


 cfg_select! {
-    unix => {
+    any(unix, target_os = "qurt") => {


This seems fishy – the QuRT module will not be used if this conditional is present.

View changes since the review

You are right, the QuRT PAL module was not being selected.
Fixed this and removed all (now-pointless) QuRT opt-ins from pal/unix/mod.rs

QuRT is not a unix target, but provides POSIX-compatible threading, file I/O and synchronization. Drop the unix family from the target spec and instead opt into the unix PAL, selecting the unix implementation of each subsystem where QuRT's POSIX layer is sufficient. This follows the pattern used by other unix-adjacent targets. Process spawning, networking and pipes remain unsupported.

Update documentation with details about how to leverage qurt, now that there's some level of libstd support

The SDK's `libc_eh.a` unwinder does not define `_Unwind_GetIPInfo`, which `eh_personality` needs on every frame, so unwinding cannot work as it stands: the linker stub the docs previously recommended aborts on the first frame. Set `panic_strategy = Abort` and keep the target out of the personality and `libunwind` arms, as Hermit and UEFI do; `panic_unwind` already falls through to its aborting implementation. The `_Unwind_*` linker stubs are no longer needed, so drop them from the documented link flags.

QuRT is not a unix target, but provides POSIX-compatible threading, file I/O and synchronization. Drop the unix family from the target spec and instead opt into the unix PAL, selecting the unix implementation of each subsystem where QuRT has sufficient POSIX compatibility. Process spawning, networking and pipes remain unsupported.

rustbot · 2026-10-21T21:20:03Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

ahumayun-qcom · 2026-10-22T13:43:51Z

@rustbot ready

rustbot assigned joboet Feb 4, 2026