[RFC] riscv-elf: Deprecate Tag_RISCV_arch

[jrtc27]

This has been an ongoing source of friction, causing confusion for
users, creating unhelpful merged arch strings when presented with
translation unit-level dynamic dispatch, and blocking creation of
legitimate objects. It has never lived up to the promise of allowing
loaders to provide user-friendly error messages when attempting to run a
binary that requires extensions not present on the current hardware, and
fundamentally cannot do so due to the semantic gap between the -march
flag used to compile each relocatable object and the higher-level intent
behind using that ISA string for that object.

The sole remaining use for Tag_RISCV_arch that I can think of is for
disassembling stripped binaries. Mapping symbols are always local, so
will be stripped, and therefore it can be ambiguous how to disassemble
an instruction present in multiple conflicting extensions (e.g. whether
an FADD.S is from F or Zfinx). In some cases this ambiguity can be
resolved from other information (e.g. a hard float ABI binary must be
using F not Zfinx), but not in the general case.

[jrtc27]

This is a request for discussion, as it strikes me that a lot of effort goes into attempting to do something useful with Tag_RISCV_arch, but most of what comes out is, at best, useless, with the sole exception of this somewhat niche case of disassembling stripped binaries. Is this how we want to keep doing things?

[jrtc27]

This should perhaps also be deprecated at this point given the existence of Zicclsm and Owhatever; as far as I know nobody's doing anything meaningful with this?

[jrtc27]

(But that's a separate issue, and isn't such an effort to support in the ecosystem)

[mengzhuo]

I can think one usecase is dynamic loader can use Tag_RISCV_arch for early extension detection.

[kito-cheng]

I agree that Tag_RISCV_arch has not served its original purpose very well. One important use case was disassembly, and mapping symbols now cover most of that, although they may be removed from stripped binaries.

We also expected the dynamic linker or Linux kernel to use this attribute for ISA checks, but no such implementation has appeared.

However, our internal tools and riscv-gnu-toolchain currently use it to determine which extensions should be enabled for simulators such as QEMU, and there is no simple replacement for this use case.

It is also a convenient way to inspect which extensions a binary may use, although function multiversioning makes the result confusing—for example, a binary may contain vector instructions even when the attribute does not include V.

Therefore, I am still hesitant to deprecate Tag_RISCV_arch.

[lenary]

While I know we have a few places to upgrade, and we lose the "what arch do we try to run this on" for emulators (which may not be accurate anyway), I think deprecation is the right long-term direction.

I don't think this info has ever been very usable by loaders in general.

I think we need to work out how to communicate this to projects doing disassembly, because they may not be heeding the symbols at the moment:

• Bolt
• LLDB

Presumably there are projects on the binutils side which also need updating?

I'm not sure how we update 3rd party disassemblers, or at the very least communicate that this tag is going away to them.