Expose elf abi on ppc64 targets

[ostylk]

Fixes #60617 (after MCP rust-lang/compiler-team#885 is accepted) by exposing the abi information on ppc64 targets.
Conditional compilation can now use cfg(target_abi = "elfv1") or cfg(target_abi = "elfv2") to determine the abi in use.

Technical details are included in the other PR #142598

original pull request text

Attempts to fix https://github.com//issues/85589 (also more information is there).

Basically the problem is that ld.lld assumes that all ppc64 object files with e_flags=0 are object files which use the ELFv2 ABI (this here is the check https://github.com/llvm/llvm-project/blob/main/lld/ELF/Arch/PPC64.cpp#L639).
This pull request sets the correct e_flags to indicate the used ABI so ld.lld errors out when encountering ELFv1 ABI files instead of generating a broken binary.

For example compare code generation for this program (file name min.rs):

#![feature(no_core, lang_items, repr_simd)]
#![crate_type = "bin"]
#![no_core]
#![no_main]

#[lang = "sized"]
trait Sized {}
#[lang = "copy"]
trait Copy {}
#[lang = "panic_cannot_unwind"]
pub fn panic() -> ! {
    loop {}
}

pub fn my_rad_unmangled_function() {
    loop {}
}

pub fn my_rad_function() {
    loop {}
}

#[no_mangle]
pub fn _start() {
    my_rad_unmangled_function();
    my_rad_function();
}

Compile with rustc --target=powerpc64-unknown-linux-gnu -C linker=ld.lld -C relocation-model=static min.rs

Before change:

$ llvm-objdump -d min
Disassembly of section .text:
000000001001030c <.text>:
		...
10010334: 7c 08 02 a6  	mflr 0
10010338: f8 21 ff 91  	stdu 1, -112(1)
1001033c: f8 01 00 80  	std 0, 128(1)
10010340: 48 02 00 39  	bl 0x10030378 <_ZN3min25my_rad_unmangled_function17h7471c49af58039f5E>
10010344: 60 00 00 00  	nop
10010348: 48 02 00 49  	bl 0x10030390 <_ZN3min15my_rad_function17h37112b8fd1008c9bE>
1001034c: 60 00 00 00  	nop
		...

The branch instructions bl 0x10030378 and bl 0x10030390 are jumping into the .opd section which is data. That is a broken binary (because fixing those branches is the task of the linker).

After change:

error: linking with `ld.lld` failed: exit status: 1
  |
  = note:  "ld.lld" "/tmp/rustcNYKZCS/symbols.o" "<1 object files omitted>" "--as-needed" "-L" "/tmp/rustcNYKZCS/raw-dylibs" "-Bdynamic" "--eh-frame-hdr" "-z" "noexecstack" "-L" "<sysroot>/lib/rustlib/powerpc64-unknown-linux-gnu/lib" "-o" "min" "--gc-sections" "-z" "relro" "-z" "now"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: ld.lld: error: /tmp/rustcNYKZCS/symbols.o: ABI version 1 is not supported

Which is correct because ld.lld doesn't support ELFv1 ABI.

[rustbot]

r? @Nadrieril

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

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

[workingjubilee]

r? @workingjubilee

I don't think we have any business with Power's ELFv1 format.

[workingjubilee]

But if we do have anything to do with it, we shouldn't be guessing.

[ostylk]

I marked this as a draft because there's now a problem that I really dislike (and ppc64 targets are currently broken):

{
    "arch": "powerpc64",
    "cpu": "ppc64",
    "data-layout": "E-m:e-Fi64-i64:64-i128:128-n32:64",
    "linker-flavor": "ld.lld",
    "llvm-target": "powerpc64-unknown-none-elf",
    "target-endian": "big",
    "target-pointer-width": "64",
    "abi": "elfv2"
}

Compiling the above mentioned program with this target file again produces the broken binary because the abi field is not passed to llvm (powerpc64-unknown-none-elf uses ELFv1 in llvm).
How exactly do we force llvm to produce ELFv2 binaries?

[nikic]

@ostylk This is determined by llvm_abiname, not target.abi.

[workingjubilee]

Yeah, there are cases where they match but in general target.abi is a cfg option for Rust userspace and target.llvm_abiname is the codegen control.

[ostylk]

Oh thanks, I somehow overlooked llvm_abiname.

I changed it to use llvm_abiname, because it really matters what the llvm codegen does. Also I changed the existing ppc64 targets to set llvm_abiname and abi (in case an app needs that information) accordingly.

[rustbot]

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

[ostylk]

@rustbot ready

[nikic]

This looks reasonable to me. I also found #60617 which asks for exposing the ELF ABI version, so I guess this fixes that issue as well.

Does exposing something new to target_abi require any special sign-off?

[nikic]

Presumably this code can't even be reached for non-ELF?

[ostylk]

Considering this if branch https://github.com/rust-lang/rust/blob/master/compiler%2Frustc_codegen_ssa%2Fsrc%2Fback%2Fmetadata.rs#L224 (the call to elf_e_flags is after the block), I assumed that it could be called for COFF files.

[workingjubilee]

My understanding of https://forge.rust-lang.org/compiler/proposals-and-stabilization.html#targets is that it requires an FCP now to add something like a field that will be visible via target_abi, since it's user-facing. Or at least MCP.

That is why I suggested splitting up codegen and user-facing parts (I mean people can poke at binaries and so in a strained sense that's "user-facing" but you know what I mean) so that the former is not stuck on process. They'll probably ship in different versions as a result but that seems completely fine.

[workingjubilee]

Though thinking about it, that seems patently silly, as we could remove tier 3 targets with just PR approval.

[workingjubilee]

Cool.

@bors r+

[workingjubilee]

??? misclick.

@bors r+

[bors]

📌 Commit cfa6731 has been approved by workingjubilee

It is now in the queue for this repository.

[workingjubilee]

Oh yeah, this is purely additive so
@bors rollup