Clarify R_<CLS>_RELATIVE optimization wording #242
Conversation
|
I think "resolves to the current dynamic shared object" conveys the same meaning: rtld binds the symbol reference to the current DSO. |
|
Hmm. I was thinking about this from the perspective of the static linker, since it'll be the one emitting RELATIVE vs. GLOB_DAT as an optimization (the context of the sentence). I guess a better wording for the entire sentence from that perspective would be:
You're right from the rtld perspective, but I don't understand the optimization discussion from that perspective. The static linker is the one deciding what relocation type to emit, and rtld is just acting on it, right? |
aaelf64/aaelf64.rst
Outdated
| @@ -1738,7 +1738,7 @@ The need for copy relocations can be avoided if a compiler generates all code re | |||
|
|
|||
| - Because the initial value of the place is not related to the ultimate target of a ``R_<CLS>_JUMP_SLOT`` relocation the addend ``A`` of such a REL-type relocation shall be zero rather than the initial content of the place. A platform ABI shall prescribe whether or not the ``r_addend`` field of such a RELA-type relocation is honored. (There may be security-related reasons not to do so). | |||
|
|
|||
| ``R_<CLS>_RELATIVE`` represents a relative adjustment to the place based on the load address of the object relative to its original link address. All symbols defined in the same segment will have the same relative adjustment. If ``S`` is the null symbol (ELF symbol index 0) then the adjustment is based on the segment defining the place. On systems where all segments are mapped contiguously the adjustment will be the same for each reloction, thus adjustment never needs to resolve the symbol. This relocation represents an optimization; it can be used to replace ``R_<CLS>_GLOB_DAT`` when the symbol resolves to the current dynamic shared object. | |||
| ``R_<CLS>_RELATIVE`` represents a relative adjustment to the place based on the load address of the object relative to its original link address. All symbols defined in the same segment will have the same relative adjustment. If ``S`` is the null symbol (ELF symbol index 0) then the adjustment is based on the segment defining the place. On systems where all segments are mapped contiguously the adjustment will be the same for each reloction, thus adjustment never needs to resolve the symbol. This relocation represents an optimization; it can be used to replace ``R_<CLS>_GLOB_DAT`` when the symbol resolves to the current dynamic shared object and is not pre-emptable. | |||
There was a problem hiding this comment.
I interpreted resolves to the current dynamic shared object as not including the cases when the symbol could be pre-empted. However it maybe one of those cases where knowing the answer makes it easier to make that interpretation.
I do think the current wording could do with some clarification, particularly as RELATIVE relocations are used in position independent executables.
May I suggest the alternative wording:
This relocation represents an optimization; a static linker can replace ``R_<CLS>_GLOB_DAT`` when the symbol is known at static link time to always resolve to the current link unit.
I've not explicitly mentioned pre-emptable but I think the always resolve catches that.
There was a problem hiding this comment.
That alternative wording sounds great to me; I'd maybe say "a static linker can use it to replace" or "a static linker can replace R_<CLS>_GLOB_DAT with it when" just to be explicit, but it's exactly what I was going for. Did you want to create a separate PR/commit for that or just edit this one?
There was a problem hiding this comment.
It would be easiest for me if you can choose one of your alternatives (use it to) or (with it) and update this PR, I'm happy with either variation! The ABI unfortunately uses merge and rebase rather than merge and squash, so to avoid a load of fixup commits we do a squash before merging. With such a simple change you may as well just force-push a replacement.
The company prefers for us not to edit PRs, so it is either update this one or submit a new PR which seems like more work than is necessary.
The optimization is applied by the static linker, so we should reword the sentence from that perspective. Thanks to @smithp35 for suggesting the wording.
smeenai
changed the title
|
Thanks, I updated the wording with your suggestion. I also updated the PR title and description to match the commit, because I wasn't sure which one would be ultimately used. |
|
Can we merge this now? :) |
|
Yes :) As per @smithp35's previous comments. |
The optimization is applied by the static linker, so we should reword
the sentence from that perspective. Thanks to @smithp35 for suggesting
the wording.