target tier 3 support for hexagon-unknown-qurt

[androm3da]

Proposal

Add target tier 3 support for QuRT RTOS on Hexagon.

Motivation, rationale

QuRT is the most widely deployed OS on Hexagon ISA cores. It's used in compute DSPs, audio DSPs, and more. It's likely that it's the only OS used on the Hexagon cores in commercial Snapdragon/Dragonwing devices.

Today, users can deploy rust no_std programs to QuRT targets using the hexagon-unknown-none-elf baremetal target. But having access to libstd opens up the number of use cases significantly.

• QuRT has support for large portions of POSIX dependencies of libc including threads, filesystems, time, signals.
• As it has been for the other hexagon targets, the contributions made to support hexagon-unknown-qurt will be made under the standard Rust license.
• I'll (@androm3da) be the maintainer and will continue to seek out additional maintainers for this and the other hexagon targets.
• QuRT doesn't have interactive shells, it wouldn't make sense as a platform to host Rust tools. So it'll be designated strictly as a cross-compiled target.
• Existing clang toolchains use hexagon-unknown-elf (from hexagon-clang) as a generic target that can include QuRT and users/build systems targeting QuRT explicitly add the necessary include, library paths. Writing portable code for QuRT and other OSs can be challenging or awkward in the status quo. I believe this will stay this way but I don't believe that Rust using hexagon-unknown-qurt instead should cause problems. This is a good subject for discussion in the MCP because it's identified as a concern when creating new targets, including tier 3 ones.

Target Policy

The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy.

Yes, confirmed.

Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries.
... the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library.

Yes: this target will use rust-lld by default and optionally the open-source eld linker. The integrated MC assembler or llvm-mc assembler can be used.

ncorporating the target and redistributing any resulting compiled binaries (e.g. built libraries, host tools if any) must not impose any onerous license requirements on any members of the Rust project, including infrastructure team members and those operating CI systems.

The terms of the Hexagon SDK are not onerous. Also: the SDK is freely downloadable.

Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate),

Yes: I plan to implement as much of std as is supported by QuRT.

Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target.

Confirmed: the maintainers will not intervene progress of other PRs for issues related to this target.

Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.

Acknowledged.

Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target

The integrated LLVM MC assembler or llvm-mc can be used.

Mentors or Reviewers

I expect to do the work but welcome mentorship from @bjorn3 or @tgross35 or anyone else on the team willing to provide guidance.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Note

Concerns (0 active)

• legal-review resolved in this comment

Managed by @rustbot—see help for details.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[tgross35]

Discussed on the Zulip stream that hexagon-qurt is probably a better name than hexagon-unknown-qurt for this since there is only one vendor, but we already have two hexagon-unknown-* targets. @androm3da is going to submit another MCP renaming those targets to drop the unknown. So, seconding with the following condition on name:

1. If an MCP renaming hexagon-unknown-* to hexagon-* targets goes through, we'll call this hexagon-qurt.
2. If that MCP doesn't go through, we can still add this target but call it hexagon-unknown-qurt to be consistent. (Renaming later remains an option.)

@rustbot second

Cc compiler leads @wesleywiser @davidtwco since this is about a new target. There is a PR adding the target rust-lang/rust#147173.

[davidtwco]

I'm fine with the naming either way, but can you go through the target tier policy and reply with an acknowledgement of each requirement - like in rust-lang/rust#146848.

[androm3da]

I'm fine with the naming either way, but can you go through the target tier policy and reply with an acknowledgement of each requirement - like in rust-lang/rust#146848.

Ok, will do. I hit some of the points in the bullets but I'll make it more explicit and exhaustive like the reference. Thanks.

[Urgau]

There is a pending legal review, #t-compiler/major changes > target tier 3 support for hexagon-unknown… compiler-team#919 @ 💬.

@rustbot concern legal-review

[tgross35]

Per #t-compiler/major changes > target tier 3 support for hexagon-unknown… compiler-team#919 @ 💬,

@rustbot resolve legal-review

[rustbot]

The final comment period is now complete, this major change is now accepted. 🎉

As the automated representative, I want to express gratitude to the author for their work and everyone else who contributed to this major change proposal.

If you think this major change shouldn't have been accepted, feel free to remove the major-change-accepted label and reopen this issue.

Note

Further progress is now tracked over at rust-lang/rust#148982.