Add aarch64-unknown-switch-libnx target

[leo60228]

This adds a target for Nintendo Switch homebrew using the devkitA64 toolchain. It can be built using the (disabled) CI Docker image.

Needs to be done before merge:

• Upstream backtrace-rs changes - Support Linkle's DWARF implementation for target_env = "devkita64" backtrace-rs#361, devkitA64 -> libnx backtrace-rs#362
• Upstream libc changes - Add bindings for target_env = "libnx" libc#1829
• Upstream LLVM changes (these are only necessary for ELF TLS, which might not be needed) - 5e14dfe48843b5860d1ab3e350b97658bd087b72
• Find a way to avoid depending on GCC-version-specific paths - c94e84fcb508bb70ad58b57e72c708396fa31484

Non-blocking issues:

• It'd be nice if we could use LLD, but I couldn't get it to work
• Currently, DWARF info is stored in the romfs (filesystem embedded in applications). It'd be preferable to have it in .rodata (like how unwind information works), but this doesn't seem to be supported by GNU ld.
• Linker arguments should be changed to target options when possible (I tried to do this in a reverted commit, but I inexplicably get an undefined instruction when starting the application)

I have an example program for this target at https://github.com/leo60228/libnx.rs.

Some discussion on this target can be found at https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/homebrew.20target.20bikeshedding.

[rust-highfive]

r? @dtolnay

(rust_highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

⚠️ Warning ⚠️

• These commits modify submodules.

[dtolnay]

This is going to require review from the compiler team.

r? @pnkfelix

[leo60228]

Going through the Tier 3 target policy RFC:

• Any new tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. - me
• Tier 3 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 as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. - see Zulip topic linked above
• The target must not introduce license incompatibilities. - as far as I know this is not the case
• Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). - ✔️
• The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the new target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by src/tools/tidy/src/deps.rs in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. - ✔️
• If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance, rustc built for 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. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3. - N/A
• New targets should not require proprietary (non-FOSS) components to link a functional binary or library. - ✔️
• Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for any target with a standard memory allocator, std for targets with an operating system), but may leave some code unimplemented!(), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. - I've been either returning an error or using stubs instead of panicking, but that should be close enough?
• The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary. - not sure where to put this, but the CI scripts should work
• 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 suggests a block on the PR based on the target. (A PR author may choose to help with a tier 3 target, but is not required to.) - this shouldn't be the case
• Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. - well, I'll wait for CI to pass, but this should be the case
• In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target. - no related targets are currently supported, but I've tried to be careful about this anyway (I know @jam1garner is working on another Switch target)

[leo60228]

(I have a shallow clone of this repo, but GitHub doesn't support force pushes from shallow clones. However, GitHub does support doing a git reset --hard through their REST API, so I can reset to the common ancestor then do a normal push. However, this can't be done atomically, and if a PR branch has no new commits it'll be automatically closed.)

[leo60228]

After thinking about it, I've decided that this is a better solution than emulating it using seek.

[leo60228]

I'm switching over to aarch64-unknown-switch-libnx based on a discussion on the libnx IRC.

[leo60228]

Due to rust-lang/libc#1829 (comment), I'm marking this as ready for review.

[leo60228]

Rebased. Note that libbacktrace will likely break very badly on this platform, but backtraces should Just Work\™ once #74682 is merged.

[leo60228]

@JohnCSimon Done.

[leo60228]

Is there any update on review of this PR?

[bors]

☔ The latest upstream changes (presumably #75110) made this pull request unmergeable. Please resolve the merge conflicts.

[Dylan-DPC-zz]

@leo60228 if you can resolve the conflicts, I will get this reviewed as soon as possible

[leo60228]

Sorry, I've been kind of procrastinating working on Rust recently. I'll start working on rebasing in the next few days (I'm getting back to my desktop on Sunday).

[JohnCSimon]

Triage: @leo60228 - Thanks for your contribution, but this has sat idle for a few weeks, I'm closing this as inactive, please feel free to reopen if you want to continue this PR.