Support ILP32 on RV64 in psABI

[Liaoshihua]

This pull request adds a new e_flags X32. It occupies the sixth bit of e_flags layout.

We have initially implemented rv64 ilp32 on the gnu toolchain and kernel.
Details in this link.

@guoren83 @palmer-dabbelt @kito-cheng

[jrtc27]

Regardless of whether we want it, x32 is completely the wrong name for it. x32 comes from the x86, x86_64 and (awful) x64 terminology specific to x86.

[jrtc27]

I'll also note that, normally, ILP32-on-64 ABIs use ELFCLASS32, not ELFCLASS64. This is complicated on RISC-V by the fact that there is a single EM_RISCV, not separate EM_RISCV32 and EM_RISCV64.

[Liaoshihua]

I'll also note that, normally, ILP32-on-64 ABIs use ELFCLASS32, not ELFCLASS64. This is complicated on RISC-V by the fact that there is a single EM_RISCV, not separate EM_RISCV32 and EM_RISCV64.

In ILP32-on-RV64, we used ELFCLASS32 and EM_RISCV. X32（Let's temporarily call it this name) is added to distinguish between ilp32 on RV64 and ilp32 on RV32 . I think this e_flag is necessary.

This is the ELF Header which generated by ILP32-on-RV64
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: RISC-V
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 24620 (bytes into file)
Flags: 0x21, RVC, X32, soft-float ABI

[kito-cheng]

I would prefer using something like register a new e_machine value EM_RISCV64_X32 or EM_RISCV64_ILP32 rather than use a e_flags for two reason: the flags only used for ELFCLASS32, and it's a wast to ELFCLASS64, use new e_machine could prevent old tool interpreter that as a normal RISC-V 32 binary

[Liaoshihua]

I would prefer using something like register a new e_machine value EM_RISCV64_X32 or EM_RISCV64_ILP32 rather than use a e_flags for two reason: the flags only used for ELFCLASS32, and it's a wast to ELFCLASS64, use new e_machine could prevent old tool interpreter that as a normal RISC-V 32 binary

I could not agree with you.

1. There are not EM_RISCV64 or EM_RISCV32 in RISC-V, using a new e_machine value EM_RISCV64_X32 means we have to add EM_RISCV64 and EM_RISCV32 . This is maybe a more serious waste than "it's a wast to ELFCLASS64”
2. In situations similar to mips-n32 and aarch64_ilp32, them use the same e_machine value with N64 or LP64 ,LLP64. Unable to prove such a major flaw, I tend to follow them.

[kito-cheng]

e_machine is 16 bit value, and use as sequence number, so we still have 2^16 - 248 = 65288 to use, but e_flags is use as bit vector, and reserved 8 bit for non-std use, and we also used 5 bit, so we have only 19 bits left, and adding EF_RISCV_X32 make it become 18 bits left.

So compared to e_flags, e_machine has much larger room to use (waste :P).

[Liaoshihua]

OK, you convinced me.
So do we need to set EM_RISCV32 and EM_RISCV64 as well? And what number should be chosen?

[kito-cheng]

Seems like it should be happened here, we could send request to [email protected] and https://groups.google.com/g/generic-abi , but I would like to pick an random value before we reach further consensus.

However I know a random value might be a bit too vague, maybe we could tentatively use 1243 (EM_RISCV + 1000), and update it in this PR after it's registered later.

[asb]

OK, you convinced me. So do we need to set EM_RISCV32 and EM_RISCV64 as well? And what number should be chosen?

I don't have an overly strong view on EM_RISCV_X32 (though Kito makes a good point about eflags bits being scarce), but don't see why we'd need to introduce EM_RISCV32 and EM_RISCV64 as well at this point - it feels like it would cause confusion with no real gain.

[jrtc27]

The world would have been better if EM_RISCV had been split in two like that, but it wasn't, so we need to live with that, and trying to retroactively do it is a bad idea. So I agree with Alex.