Define GOT-Relative data relocation about abi-aa HOT 3 CLOSED

Thanks for the suggestion and the motivating details. If I've understood this correctly this is a data relocation, that generates a GOT entry, and resolves to the 32-bit pc-relative offset to that GOT entry. The GOT entry may point to an entity that isn't DSO local so this may require a dynamic relocation.

I think the expression we use for that for the equivalent instruction relocations is G(GDAT(S+A))- P
GDAT(S+A) generates the GOT entry and the dynamic relocation R__GLOB_DAT(S+A).
G(GDAT(S+A)) is the address of that GOT entry
G(GDAT(S+A)) - P is the offset to the GOT entry.

I note that no linker currently implements the GDAT(S+A) correctly, I think LLD would implement as G(GDAT(S)) - P + A and GNU ld would ignore the addend A (#217) that is probably best handled by issue 217 so I suggest we keep the expression consistent.

I think this would result in:

GOT-relative data relocation
...
315 | - | R_<CLS>_GOTREL32 | G(GDAT(S+A))- P | Write bits [31:0] of X at byte-aligned place P. This represents a 32-bit offset relative to GOT, treated as signed; Check that -2^31 <= X < 2^31 |

I think the fastest way to progress this would be to submit a pull request with the suggested changes. Otherwise it is waiting for someone to write it up.

To me (as an individual) the proposal looks reasonable. I'm wondering if it is worth defining a 64-bit R__GOTREL64 while we are here. My instinct is that we wait till something needs it.

from abi-aa.

Thanks for the suggestion and the motivating details. If I've understood this correctly this is a data relocation, that generates a GOT entry, and resolves to the 32-bit pc-relative offset to that GOT entry. The GOT entry may point to an entity that isn't DSO local so this may require a dynamic relocation.

Correct

I think the expression we use for that for the equivalent instruction relocations is G(GDAT(S+A))- P GDAT(S+A) generates the GOT entry and the dynamic relocation R__GLOB_DAT(S+A). G(GDAT(S+A)) is the address of that GOT entry G(GDAT(S+A)) - P is the offset to the GOT entry.

Oh ok that makes sense. I actually didn't notice GDAT(S+A) before but that equation works also.

I note that no linker currently implements the GDAT(S+A) correctly, I think LLD would implement as G(GDAT(S)) - P + A and GNU ld would ignore the addend A (#217) that is probably best handled by issue 217 so I suggest we keep the expression consistent.

I think this would result in:

GOT-relative data relocation
...
315 | - | R_<CLS>_GOTREL32 | G(GDAT(S+A))- P | Write bits [31:0] of X at byte-aligned place P. This represents a 32-bit offset relative to GOT, treated as signed; Check that -2^31 <= X < 2^31 |

I think the fastest way to progress this would be to submit a pull request with the suggested changes. Otherwise it is waiting for someone to write it up.

Can do. Wanted some early feedback to see if there would be any hard no's.

To me (as an individual) the proposal looks reasonable. I'm wondering if it is worth defining a 64-bit R__GOTREL64 while we are here. My instinct is that we wait till something needs it.

I'm also in the boat of reserving it until it's needed.

from abi-aa.

Submitted #223

from abi-aa.