Add support for hexagon-unknown-qurt target

[androm3da]

MCP: rust-lang/compiler-team#919
Fixes #148982.

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
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

[tgross35]

Procedurally, adding a new T3 target requires a MCP (Major Change Proposal), which is an issue template at https://github.com/rust-lang/compiler-team/issues. See rust-lang/compiler-team#911 for a recent example.

[jieyouxu]

Procedurally, adding a new T3 target requires a MCP (Major Change Proposal), which is an issue template at rust-lang/compiler-team/issues. See rust-lang/compiler-team#911 for a recent example.

(I believe that was revised to only require a PR (with the target tier policy for T3 filled out), and assigned to one of the compiler co-leads. For certain targets (especially the more obscure ones) we may ask for an MCP for further discusssions. This target seems... rather obscure, so an MCP seems beneficial.)

r? compiler_leads

[bjorn3]

What is the license of this SDK? Maybe you could link to the page that links to the zip file and presumably also the license.

[androm3da]

It's a proprietary SDK, hopefully the change makes this clearer.

[androm3da]

Procedurally, adding a new T3 target requires a MCP (Major Change Proposal), which is an issue template at rust-lang/compiler-team/issues. See rust-lang/compiler-team#911 for a recent example.

(I believe that was revised to only require a PR (with the target tier policy for T3 filled out), and assigned to one of the compiler co-leads. For certain targets (especially the more obscure ones) we may ask for an MCP for further discusssions. This target seems... rather obscure, so an MCP seems beneficial.)

r? compiler_leads

Happy to fill out an MCP - that makes sense to me.

But in filling it out, I think I've hit a roadblock that makes me consider abandoning this PR.

Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge.

Of course - this policy makes perfect sense. For this particular target, it's generally targeted using the hexagon-unknown-elf triple when using clang -- not hexagon-unknown-qurt. This is unfortunate because it also means that clang doesn't emit preprocessor defines like __QURT__ because there's no distinction. But in places like Rust's libc, I want to be able to guard things with #[cfg(target_os = "qurt")].

Sorry - perhaps this discussion might be better on the MCP issue rather than this PR. We already have an hexagon-unknown-none-elf target in rustc. Should I just use that one instead or does this constitute a "very good reason to diverge"? It's definitely the case that some folks use other non-QuRT, non-Linux OSs on Hexagon DSPs, but -- for now -- this is probably only internal to Qualcomm.

[tgross35]

Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge.

Of course - this policy makes perfect sense. For this particular target, it's generally targeted using the hexagon-unknown-elf triple when using clang -- not hexagon-unknown-qurt. This is unfortunate because it also means that clang doesn't emit preprocessor defines like __QURT__ because there's no distinction. But in places like Rust's libc, I want to be able to guard things with #[cfg(target_os = "qurt")].

Why doesn't Clang have a -qurt target, or why isn't it used? If there is a need to configure on qurt vs. not qurt (e.g. different system interfaces) then that's probably enough to justify a new Rust target. It just seems weird that Clang doesn't have the target if it's useful.

[androm3da]

Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge.

Of course - this policy makes perfect sense. For this particular target, it's generally targeted using the hexagon-unknown-elf triple when using clang -- not hexagon-unknown-qurt. This is unfortunate because it also means that clang doesn't emit preprocessor defines like __QURT__ because there's no distinction. But in places like Rust's libc, I want to be able to guard things with #[cfg(target_os = "qurt")].

Why doesn't Clang have a -qurt target, or why isn't it used? If there is a need to configure on qurt vs. not qurt (e.g. different system interfaces) then that's probably enough to justify a new Rust target.

The Hexagon SDK toolchain ships with hexagon-clang -- this canonicalizes as hexagon-unknown-elf. By default hexagon-clang builds with a common C library and links in a crt0 for a baremetal OS. But for targeting QuRT, that behavior is explicitly overridden when invoking hexagon-clang to compile or link to additionally use QuRT include paths and link against QuRT libraries/crt0 instead. I don't know for sure but I suppose it's "simpler" this way -- or maybe it's just a historical thing that stays that way due to momentum.

If there is a need to configure on qurt vs. not qurt (e.g. different system interfaces) then that's probably enough to justify a new Rust target.

The Hexagon Linux target is not supported by the Hexagon SDK and so far that's really the only toolchain that's used to target QuRT. In practice, no commercial users of Hexagon target anything other than QuRT on Hexagon architecture. So IMO it's an oversimplification that happens to work. The opensource clang+llvm toolchain (see build recipe ) could conceivably target QuRT but is missing a C library that would work with QuRT, so in practice no one uses it for that -- yet.

It just seems weird that Clang doesn't have the target if it's useful.

My understanding is that clang could take a hexagon-unknown-qurt triple and it would probably work reasonably well if it were interpreted as having the same behavior as hexagon-unknown-none-elf / hexagon-unknown-elf. I don't recall for sure but I suppose the clang driver might do just that. And if not, it's not hard to change it to do so. But -- it's untested and definitely not how it's been done by the Hexagon SDK over the years. I hope I am just being overly cautious here but Rust's policy regarding target names makes a lot of sense to me.

[androm3da]

This target seems... rather obscure, so an MCP seems beneficial.)

Thanks - MCP created rust-lang/compiler-team#919

[tgross35]

These all come from the hexagon toolchain, right? If they are needed then it's probably worth mentioning the toolchain in the "requirements" section. If not, maybe add a comment here that the defaults also work or provide an alt setup.

[androm3da]

Added

[rustbot]

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.

[tgross35]

@bors r=davidtwco,tgross35

[bors]

📌 Commit ecfc642 has been approved by davidtwco,tgross35

It is now in the queue for this repository.