Support function vs code pointer relocations on CHERI-RISC-V

[jrtc27]

• [NFC][Target][AsmPrinter] Introduce and use lowerCheriCodeReference
• [BinaryFormat][RISCV] Reserve R_RISCV_CHERI_CAPABILITY_CODE
• [RISCV] Add MC support for .chericap %code(expr)
• [ELF][RISCV] Support R_RISCV_CHERI_CAPABILITY_CODE and R_RISCV_FUNC_RELATIVE
• [RISCV] Use new %code(expr) for lowerCheriCodeReference

[arichardson]

I've not really been following these changes so this is from an outside view: the name code is somewhat confusing. What is the difference between function and code? Would a name something like local_func or local_code make more sense to distinguish trampoline vs no trampoline?

[jrtc27]

The names are what we settled on for Morello, and are documented in aaelf64-morello. "Code" is intended to capture that you are referring to a specific point in the code, i.e. an instruction, whereas "function" is intended to capture that it's a more abstract reference where you just want to be able to call it (whether for a direct call or a function pointer), you don't actually care about the specific instruction you're pointing to, and therefore it's appropriate to insert trampolines.

[arichardson]

The names are what we settled on for Morello, and are documented in aaelf64-morello. "Code" is intended to capture that you are referring to a specific point in the code, i.e. an instruction, whereas "function" is intended to capture that it's a more abstract reference where you just want to be able to call it (whether for a direct call or a function pointer), you don't actually care about the specific instruction you're pointing to, and therefore it's appropriate to insert trampolines.

Thanks for the explanation. That makes sense to me. I do feel like it would be good to capture that it's a direct reference, but of course that conflicts with the need to keep names short.

[jrtc27]

The names are what we settled on for Morello, and are documented in aaelf64-morello. "Code" is intended to capture that you are referring to a specific point in the code, i.e. an instruction, whereas "function" is intended to capture that it's a more abstract reference where you just want to be able to call it (whether for a direct call or a function pointer), you don't actually care about the specific instruction you're pointing to, and therefore it's appropriate to insert trampolines.

Thanks for the explanation. That makes sense to me. I do feel like it would be good to capture that it's a direct reference, but of course that conflicts with the need to keep names short.

Yeah. Given the cryptic names that feature in psABIs and assembly syntax I think that's more a case of ensuring we have adequate documentation?

[arichardson]

Ultimately it's just a name and doesn't matter but I feel it would be good to make it obvious to readers less familiar with the intricacies of these relocations. But yeah having good documentation should address that.

[jrtc27]

Ultimately it's just a name and doesn't matter but I feel it would be good to make it obvious to readers less familiar with the intricacies of these relocations. But yeah having good documentation should address that.

Are you happy for this to be merged then once Dapeng can confirm I didn't screw something up?

(At some point soon I'll go update our psABI to document the relocations)

[arichardson]

Code all looks good to me. Only minor suggestion is maybe we should add a doc comment somewhere to ensure future readers understand the distinction.

[arichardson]

A comment here or on addCapReloc() might be nice, just to make future readers don't think they need to set isCode=true for functions.

[arichardson]

And maybe a comment here?

[dpgao]

This all looks good to me.

[jrtc27]

Code all looks good to me. Only minor suggestion is maybe we should add a doc comment somewhere to ensure future readers understand the distinction.

Please check if you think the comments I've added make it clear

[arichardson]

Code all looks good to me. Only minor suggestion is maybe we should add a doc comment somewhere to ensure future readers understand the distinction.

Please check if you think the comments I've added make it clear

Looks great! Thanks for adding them.

[jrtc27]

(Updated to s/pointer/symbol/ as "symbol is a function pointer" is ambiguous as to whether that means "of type STT_FUNC" or "of type STT_OBJECT that holds a pointer", even if clear from the context)