[AAELF64] Document R_AARCH64_FUNCINIT64 #336
Conversation
smithp35
left a comment
smithp35
left a comment
There was a problem hiding this comment.
Main material change that I think we need is to move the relocation code into the static relocation space. As mentioned in the inline comment the ABI uses the dynamic relocation code for relocations that a dynamic linker needs to implement. IIUC this relocation code generates a dynamic relocation (R_AARCH64_IRELATIVE), but isn't itself dynamic.
I've also left a comment over whether to make a separate table for Structure Protection relocations. I'll also make the same comment on the R_AARCH64_PATCHINST issue as that is related.
| +------------+------------+-----------------------------+------------------------------------+-------------------------------------------+ | ||
| | 1032 | 188 | R\_<CLS>\_IRELATIVE | Indirect(Delta(S) + A) | See note below. | | ||
| +------------+------------+-----------------------------+------------------------------------+-------------------------------------------+ | ||
| | 1033 | \- | R\_AARCH64\_FUNCINIT64 | Indirect(S + A) | See note below. | |
There was a problem hiding this comment.
The ABI would consider R_AARCH64_FUNCINIT64 a static data relocation as it is handled by a static linker. The R_AARCH64_IRELATIVE relocation that the static linker produces is the dynamic relocation.
I think we'd likely want to make a new "operator" rather than use Indirect(S+A), something like FuncInit(S) that we add to https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#5733relocation-operations that would contain text similar to what you've put in the See note below.
I think we've got a couple of alternatives for where to put the relocation. The first choice is https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#575static-data-relocations . The second is to create a new table like relocations for the pauth-abi-extension
https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#5712relocations-for-pauth-abi-extension something like "Relocations for the structure protection extension" which could also include R_AARCH64_PATCHINST.
There are a couple of benefits to separating out into a "Relocations for the structure protection extension", the first is that other linker's can know when to expect to see this relocation. For example if my toolchain/platform doesn't support structure protection extension I don't need to implement these relocations. The second is that we can easily mark the extension as ALPHA which gives us more freedom to make potentially breaking changes.
The downside is that R_AARCH64_PATCHINST is more generally useful outside the extension, however I think it could be moved out to the general instruction relocations if/when binutils implements it.
There was a problem hiding this comment.
The ABI would consider R_AARCH64_FUNCINIT64 a static data relocation as it is handled by a static linker. The R_AARCH64_IRELATIVE relocation that the static linker produces is the dynamic relocation.
That makes sense. I was imagining that a toolchain could theoretically support FUNCINIT64 with a symbol operand in .rela.dyn and in that case it could also act as a dynamic relocation. This is not very different from e.g. ABS64 which can act as both, but ABS64 is in the static relocation range so we could have FUNCINIT64 be there as well.
I think we'd likely want to make a new "operator" rather than use Indirect(S+A), something like FuncInit(S) that we add to https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#5733relocation-operations that would contain text similar to what you've put in the See note below.
The definition of Indirect is:
Indirect(expr)represents the result of calling expr as a function. The result is the return value from the function that is returned inr0. The arguments passed to the function are defined by the platform ABI.
So FuncInit would have the same semantics as Indirect but the argument must be a static link-time constant modulo load bias. All existing uses of Indirect already meet the criteria (issues raised in #337 aside, which are likely theoretical), so maybe we could change Indirect to require this.
I think we've got a couple of alternatives for where to put the relocation. The first choice is https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#575static-data-relocations . The second is to create a new table like relocations for the pauth-abi-extension
https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#5712relocations-for-pauth-abi-extension something like "Relocations for the structure protection extension" which could also include R_AARCH64_PATCHINST.There are a couple of benefits to separating out into a "Relocations for the structure protection extension", the first is that other linker's can know when to expect to see this relocation. For example if my toolchain/platform doesn't support structure protection extension I don't need to implement these relocations. The second is that we can easily mark the extension as ALPHA which gives us more freedom to make potentially breaking changes.
That's fine with me. The extensions here are relatively simple so I think they only deserve a new section in this file and not a full blown spec like memtagabielf64.
If you would like to upload a PR tomorrow as mentioned in #317 we can make it cover both and let's continue the discussion there. Otherwise I'll update this one.
The downside is that R_AARCH64_PATCHINST is more generally useful outside the extension, however I think it could be moved out to the general instruction relocations if/when binutils implements it.
That makes sense.
As a side note, one thing that I've never really liked about the separate tables is that it is easy to accidentally allocate a conflicting relocation type number by adding 1 to the number at the end of one of the tables without checking the others. I needed to be careful to make sure that my new relocation type numbers did not conflict with any of the PAuth ones. Eventually we will close the gap between the last main table relocation and the first PAuth relocation, so leaving gaps is just delaying the problem. I probably would prefer this document to be organized as a large table with all the relocations in numerical order, possibly with each entry annotated to indicate which extension they belong to.
|
|
||
| ``R_<CLS>_IRELATIVE`` represents a dynamic selection of the place’s resolved value. The means by which this relocation is generated is platform specific, as are the conditions that must hold when resolving takes place. | ||
|
|
||
| ``R_AARCH64_FUNCINIT64`` represents a dynamic selection of the place’s resolved value, and generates a ``R_AARCH64_IRELATIVE`` relocation in the binary. The operand to ``R_AARCH64_IRELATIVE`` is an addend relative to the binary load address, so the symbol operand to ``R_AARCH64_FUNCINIT64`` must have a statically known address. |
There was a problem hiding this comment.
As mentioned in the previous comment I think it would be better to use a new operator which we could some or all of this text to.
From the LLD implementation the R_AARCH64_FUNCINIT64 target symbol must not have STB_LOCAL or STB_GNU_INDIRECT binding in addition to having a statically known address.
There was a problem hiding this comment.
From the LLD implementation the R_AARCH64_FUNCINIT64 target symbol must not have STB_LOCAL or STB_GNU_INDIRECT binding in addition to having a statically known address.
With the LLD implementation there are other factors such as whether -Bsymbolic and -shared are passed, which control whether the symbol has a statically known address (modulo load bias). It may be best to simply state the restriction, which implies that it can't be global (in some circumstances) or an ifunc.
|
Superseded by #340. |
2 participants
Fixes #329.