Expose `target_abi = "elfv{1,2}"` on `powerpc64-any-unixy-elfy` targets

[workingjubilee]

Proposal

This is a formal proposal that, presuming first that MCP#884 is accepted, we also accept PR rust-lang/rust#142321 to address rust-lang/rust#60617 by exposing the ABI version for all powerpc64-anything-using-elf tuples. This will allow code for these targets that depends on specifics of the POWER ISA's ELF ABI versions to cfg on these qualities, without depending on false equivalences. For instance, currently Rust programmers can only cfg by assuming things like,

• cfg(all(target_env = "gnu", target_endian = "big")) means ELFv1, but this can be made false by recompiling the GNU code against the new ABI with minimal changes at best, which means a distro can simply do that.
• cfg(all(target_env = "gnu", target_endian = "little")) means ELFv2, which is a safer assumption but is also likely not immune to recompiling.
• cfg(target_env = "musl") means ELFv2, which is true-r because the musl libc only formally supports ELFv2, but we do have targets that depend on the musl libc modified to support a new target, in ways that are not likely to be upstreamed, and some of them also expose target_env = "musl" because the equivalence is true-enough.
• cfg(target_os = "openbsd") means ELFv2, which is true if compiling against a recent-enough OpenBSD, which... okay you really should be doing that, OpenBSD is a "moving target" in a similar way as Rust.
• cfg(target_os = "freebsd") means ELFv2, which is true if compiling against a recent-enough FreeBSD, but this required raising our target minimum for FreeBSD in order to make it universally true, see Fix powerpc64 big-endian FreeBSD ABI rust#132150 for more on this evolution. Being able to fix the target_abi in the compiler and have libraries respond automatically would have made this path smoother.

It's much easier if we simply have cfg(target_abi = "elfv2") for PowerPC, and that way anyone who needs to key on it can simply properly do so, and if anyone needs to change a target they can simply do so, and then everything's dandy like that!

Mentors or Reviewers

me and nikic!

Process

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

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, 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

[Gelbpunkt]

I'm very much in favor of this, it helps avoid issues such as libffi-rs not building because of incorrect ABI conditional logic and allows such crates to let the compiler do the (guess)work instead.

[tgross35]

Seems like everyone is on board here. Noting that the exact next steps depend on the outcome of #884.

@rustbot second