[aaelf64-morello][aapcs64-morello] Document pure-capability benchmark ABI #365
Conversation
… ABI This has existed for several years but was never specified, so attempt to do so in key places. Omissions are likely but this should give enough detail that anyone caring about this niche within a niche can figure out any missed implications themselves.
smithp35
left a comment
smithp35
left a comment
There was a problem hiding this comment.
Thanks for the patch. I've got a few small suggestions on wording and how a linker is expected to process the note section.
|
|
||
| NT_CHERI_MORELLO_PURECAP_BENCHMARK_ABI has a Desc Size of 4, and Desc should | ||
| be interpreted as a 4-byte boolean value, with values other than 0 and 1 | ||
| reserved. |
There was a problem hiding this comment.
Some things that may be worth mentioning:
- Does the absence of the note imply a value of 0?
- Do all input objects have to have the same value?
- Is the linker expected to propagate a consolidated note into the executable/shared-object like .note.gnu.property or can it be discarded?
There was a problem hiding this comment.
For the first two, yes, that should be documented here (and the answer to both is yes). For the last one, that's not really something that's up to this spec to document, that's a CHERI ELF gABI point (to which the answer is, yes, they get propagated as they're all about annotating binaries with the details ABI variant is in use, normally incompatible if different with the compat TLS ABI as a rare exception).
| C64 symbol will always have an odd value. However, a linker should strip the | ||
| discriminating bit from the value before using it for relocation. | ||
|
|
||
| Due to the pure-capability benchmark ABI using integer BR/BLR for indirect |
There was a problem hiding this comment.
Following https://github.com/ARM-software/abi-aa/blob/main/aapcs64-morello/aapcs64-morello.rst#611general-purpose-registers could this be something like:
Due to the pure-capability benchmark ABI using a 64-bit context for indirect calls using BL/BLR, bit 0 ...
I don't have a particularly strong opinion here. If integer vs capability is a well used term in the CHERI/Morello community then leave it as is.
There was a problem hiding this comment.
I think that makes it less clear, and to me "in a 64-bit context" in the linked description means "in the context of an operand that is to be interpreted as a 64-bit integer", i.e. the context is the instruction and operand number, not that the instruction is within such a context. And yes, integer (or (integer) address) vs capability is a normal distinction to be making within CHERI. I can change it to be a bit less terse though with something like "Due to the pure-capability benchmark ABI using BR/BLR with a 64-bit integer X register for ..." if you think that would be clearer?
There was a problem hiding this comment.
I think your suggested replacement looks good to me.
"Due to the pure-capability benchmark ABI using BR/BLR with a 64-bit integer X register for ..."
| - If the symbol addresses a C64 instruction, its value is the address of the | ||
| instruction with bit 0 set (in a relocatable object, the section offset with | ||
| bit 0 set). | ||
| bit 0 set) if not using the pure-capability benchmark ABI, otherwise it is |
There was a problem hiding this comment.
I think it would be worth moving the ABI distinction further up in the paragraph, or perhaps using a full stop before otherwise.
A suggestion:
If the symbol addresses a C64 instruction, its value depends on the ABI used. If not using the pure-capability benchmark ABI the value is the address of the instruction with bit 0 set (in a relocatable object, the section offset with
Comment view bit 0 set). If using the pure-capability benchmark ABI the value is the same as for a symbol addressing an A64 instruction.
There was a problem hiding this comment.
Sure, I can try to rework this bullet point a bit more, I was trying to be minimally disruptive of the existing wording but you're right that affected the clarity here (and found this one the hardest to write at the time)
There was a problem hiding this comment.
Thanks. I agree that isn't an easy edit to make.
2 participants
This has existed for several years but was never specified, so attempt
to do so in key places. Omissions are likely but this should give enough
detail that anyone caring about this niche within a niche can figure out
any missed implications themselves.