Create new Tier 2 targets with sanitizers enabled by default

[jakos-sec]

Proposal

In the efforts of the Rust goal Rust Stabilization of MemorySanitizer and ThreadSanitizer Support, we are looking for a solution to distribute prebuilt sanitizer instrumented standard libraries. This was requested by previous reviews, in order to stabilize sanitizers that require all code to be instrumented since otherwise they generate false positives (like the MemorySanitizer and ThreadSanitizer). Currently the only way to realistically use those is with -Z build-std, but if we stabilize the sanitizers, it is odd to still be dependent on another unstable flag. This will also benefit other sanitizers (such as ASAN) to reduce false negatives.

The MCP (#943) for it resulted in the suggestion to, instead of the initially proposed rustc flag to choose a different rustlib path, make new targets which have (e.g.) ASAN enabled by default and we can use rustup to distribute standard libraries for those targets which are automatically instrumented.

I've started with rust-lang/rust#149644, but in order to distribute the prebuilt standard libraries it needs to be a Tier 2 target (hence this MCP).

I started with the target for ASAN, but ideally we would like to do the same for (MSAN, TSAN, LeakSanitizer). Particularly MSAN and TSAN need instrumented standard libraries since without whole binary instrumentation they cause false positives.

As for the naming the most voted name on zulip (#t-compiler/major changes > Create new Tier 2 targets with sanitizers… compiler-team#951 @ 💬.) for an ASAN enabled x86_64-unknown-linux-gnu target was:

• x86_64-unknown-linux-gnuasan

For completeness:

• x86_64-unknown-linux-gnu-asan (would require a cc-rs change (Add support for targets like x86_64-unknown-linux-gnu-asan cc-rs#1629))
• x86_64-asan-linux-gnu (the vendor is almost not used (apparently windows 7 does make use of it))
• x86_64-unknown_asan-linux-gnu: Appending to unknown instead of replacing it.
• x86_64_asan-unknown-linux-gnu: compiling sanitizer rt complains since the LLVM sees: Compiler-RT supported architectures: x86_64_asan (which is not a valid ARCH).
  x86_64-unknown-linux_asan-gnu: worked but I'm not sure if that's ideal either (will probably break some things parsing -linux-gnu.

Mentors or Reviewers

Mentor/Reviewer: rcvalle

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.

[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

[Kobzol]

@rustbot second

[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#151253.