[clang] [llvm] [clang][RISCV][Zicfilp] Emit RISCV function-signature-based CFI label in llvm::Function metadata (PR #111661)

[Ming-Yi Lai via cfe-commits]

mylai-mtk wrote:

> There are intentional tradeoffs here, for the ABI, which should be made carefully; in some cases, it might be the right tradeoff to reject standard-compliant code. If you've considered it, I guess I won't object. I can't find any discussion of it, though.

The reduction of unprototyped function types to prototyped no parameter function types is proposed by me in <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/434#issuecomment-2162159763>, which is accepted without much discussion/objection. I also proposed treating such usages as errors, but it looks like this part had not been taken into the spec.

> With my psABI hat on, settling on an ABI that turns out to be wrong is my big concern, but you can't find those corner cases until you try it at scale (and that's speaking from experience where we've missed things in the past for CHERI). This is probably the kind of thing that needs to be explicitly marked as experimental and with no ABI forward-compatibility guarantees, but that needs to be landed so that people can start actually using it and finding where it falls down in the real world. (But that doesn't obviate proper code review, the implementation should still be proper even if the ABI isn't stable.)

Agree. I'm pretty sure that the mangling scheme is not perfect, especially when applied to ancient C projects. With regard to forward-compatibility management, I think we can introduce versioning to Zicfilp psABI as well? (cf. Tag_RISCV_atomic_abi in `.riscv.attributes` section) @kito-cheng 

> Given the comparison with the AArch64 PAuth work, how much is building on that versus doing our own independent thing?

We did not refer to the AArch64 PtrAuth work when we devised the Zicfilp mangling scheme, and instead, our foundation was the Itanium C++ ABI. The time at which these 2 mangling schemes appeared were close, and I did not know that AArch64 was developing a similar thing back then, so adapting the Itanium C++ ABI looked like the most practical approach. 

> Is there any real-world deployment experience from that that we can make use of?

Not that I know of... The AArch64 PtrAuth work is in the main trunk for only less than 1 year, and it may take multiple years for the feature to mature, so I would say that we can surely learn some valuable things from it if we observe it long enough, but for now, I think both schemes are in a similarly nascent status, with the AArch64 PtrAuth scheme being more explicit and controllable.

https://github.com/llvm/llvm-project/pull/111661