Make code coverage measurement a requirement for Tier 2 (at least) target architectures

[briansmith]

I propose the following requirement for a target to be Tier 1 or Tier 2:

For a target P using architecture A (target_arch) to be Tier 2, there must exist a target T that has the same architecture (same target_arch) that supports the following requirements:

• mainline QEMU supports that target, such that cargo test --target=T.
• Rust's source-based code coverage must work for that target. (Presently this means that profiler builtins are enabled for the target.)
• If there is a target that A--linux-gnu and/or A--linux-musl that would meet these requirements, then one (ideally both) of these targets must be made Tier 2 before, or at the same time, as any other target with the same architecture.
• P and T must have the same calling convention / ABI.

In other words, I propose that in order for a target to be considered Tier 2 (or higher), it must be possible for us to actually run tests measure code coverage metrics for that architecture without jumping through hoops. I am not asking that every tier 2 (or higher) target support profiling because that might not be practical for us to do, e.g. aarch64-apple-ios or aarch64-pc-windows-*.

Currently there are many Tier 2 targets with architectures for which no target for that architecture supports profiler builtins. Examples: powerpc, powerpc64le, loongarch64.

Currently there are some Tier 2 targets with architectures for which it is difficult to get QEMU working. Examples: loongarch64 requires (AFAICT) either building their custom toolchain from source or using their provided binaries, which is not practical.

/cc @joshtriplett

[Noratrieb]

you'll get more responses asking this on zulip instead of here

[thomcc]

P and T must have the same calling convention / ABI.

I'm not sure there's a target supported by QEMU with the same calling convention/ABI as aarch64-apple-darwin (or any of the other aarch64-apple-*), which is a very widely used tier 2 target.

[workingjubilee]

I am not sure QEMU supports wasm guests, either.

Also, @briansmith, what do you define as "mainline" QEMU? Because as far as I can tell, QEMU's GitLab contains the Loongarch64 support.

[briansmith]

All good points. The QEMU parts of the proposal don't seem well-reasoned because it basically excludes all non-open-source operating systems, which isn't realistic.

Basically, I just want us to find a way to get to "Hey, if we just need to a single flag to the build configuration for a target to get source-based code coverage then we'll do it as part of upgrading the target to tier 2 or higher, and/or before adding target-specific language/library features like intrinsics or inline assembly. So let's add that to the checklist."

wasm32 is definitely a target where we could really benefit from source-based code coverage instrumentation, because we have wasm32 intrinsics in libcore already. It's being tracked in https://github.com/rust-lang/rust/issues/81684 and is a special case as it's more than flipping a flag.

There is a lot of evidence that in many cases it really is just a matter of flipping a flag (and ideally testing it):

• https://github.com/rust-lang/rust/pull/104304: Literally just added --enable-profiler to one line.
• https://github.com/rust-lang/rust/pull/111575: Did more, but the effective change w.r.t. source-based code coverage support was the same, just adding --enable-profiler.
• https://github.com/rust-lang/rust/pull/105389 was the same 18-character addition.

(Beyond code coverage, like https://github.com/rust-lang/rust/pull/111575 suggests, there are other configuration options that are really useful for quality assurance that should be considered too, like sanitizer support.)