ELF ABI support for RISC-V profiles

[pz9115]

When we use binaries support RISC-V profiles, it require distinguish if profiles executed compatible on different hosts.
Do we need new file heads or symbols to deal with this?

[ptomsich]

The profiles expand to individual extensions that will be represented by existing machinery in psABI (i.e. ELF headers and tags) to identify the required extensions. Consequently, we don't need any special support for RISC-V profiles: the compatibility determination remains the current subset-relationship (i.e. a binary that requires a subset of the available functionality is compatible with a machine).

Having an orthogonal mechanism in the ABI would be more error-prone (and thus not advisable) as the various software layers would then have to match up between the profiles and individual extension specification: any ELF file that requires a subset of functionality guaranteed by a profile will need to be accepted as "compatible" ... if we have profiles as a separate concept, we would still need to look at the individual extensions in a secondary compatibility relationship.

[cmuellner]

The idea was mentioned in yesterday's RISC-V GNU community call.
The intention is the following: using an orthogonal mechanism for the compatibility check that requires just testing for a bit will be much faster than parsing the complete march string and doing the compatibility check based on extension-subset-matching at run-time.

[ptomsich]

The compatibility check only occurs when loading an ELF file.
The process of installing the ELF as an executable certainly makes the subset-matching look cheap in comparison.

That said, we will forever have issues around ELF files that require only a subset of the function provided by a profile (e.g., someone decides to compile their library just for "rv64gc" to have a single tested binary)... or, where a toolchain is smart enough to mark a dependency on the needed extensions only instead of "everything in the profile".

Next problem will be upgrading from RVA22 to RVA24: this will just create convoluted compatibility check logic (e.g. is "RVA22 + vectors" compatible with RVA24) in the long term.

[kito-cheng]

Having a profile tag might not helpful to checking the binary is OK for platform or host, and I have similar concern as @ptomsich, give 2 more concrete example to show what could be happened:

---

we have a binary is rva24-compatible, and rva24 is including everything with rva22, AND plus A ext., B ext. which not existed in rva22.

So could we say that binary is compatible with rva22? I think yes - because the binary having every mandatory extensions required by rva22. but does it able to safe to run on any rva22 compatible platform? - No, because that might missing A ext. and B ext. support.

---

And the situation will happened even within single profile - we have a binary built with rva22 plus a vendor Xfoo., could we said it's rva22 compatible binary? Yes - because it satisfied every requirement of rva22.

Does it able to safe to run on any rva22 compatible platform? - No, because not every rva22 compatible platform implement Xfoo.

---

IMO everything should just using arch info is enough.