Define GOT-Relative data relocation about riscv-elf-psabi-doc HOT 8 CLOSED

It sounds like a reasonable addition to the psABI. I'd make a change to https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc and send a pull request.

from riscv-elf-psabi-doc.

Submitted #402

from riscv-elf-psabi-doc.

Sorry for late reply, just back from GNU tools cauldron, I think generally it's OK to add new relocation which is useful, especially they are already accepted by other architecture, anyway, just need to make sure our linker friends are also happy with that :P

from riscv-elf-psabi-doc.

Can you add an example with detailed code sequences how R_RISCV_GOT32_PCREL is going to be useful?

from riscv-elf-psabi-doc.

Can you add an example with detailed code sequences how R_RISCV_GOT32_PCREL is going to be useful?

The immediate use will be for the relative vtables c++ ABI. Currently a relative vtable will look like this:

  .section .rodata.vtable
vtable:
  .word 0  // offset to top
  .word vtable.rtti.proxy - (vtable+8)  // offset between dso-local proxy symbol and first vtable func
  .word foo@PLT - (vtable+8)  // offset between PLT entry for foo and first vtable func

  .section .data.relro.vtable.rtti_proxy
  .hidden vtable.rtti_proxy
vtable.rtti_proxy:
  .quad vtable.rtti  // pointer to the actual rtti struct

Accesses to the rtti struct are done using a relative load to get the address of vtable.rtti_proxy followed by a load to get vtable.rtti:

        ld      a1, 0(a0)  // load vtable from an object (a1 points to the 3rd entry in the vtable which is the first virtual function)
        lw      a2, -4(a1)  // load 32-bit offset (vtable.rtti.proxy - (vtable+8))
        add     a1, a1, a2  // add the offset back to the vtable address to get `vtable.rtti.proxy `
        ld      a1, 0(a1)  // deref to get `vtable.rtti`

The proxy is needed to ensure the vtable contains only static relocations. Functionally, this proxy symbol acts the same as the GOT, so the offset calculation between the proxy and PC can instead be the offset between the GOT entry and PC. This is similar to x86's R_X86_64_GOTPCREL and can be denoted with @GOTPCREL. So the new relative vtable layout would be:

  .section .rodata.vtable
vtable:
  .word 0  // offset to top
  .word vtable.rtti@GOTPCREL-4  // offset between GOT entry for vtable.rtti and first vtable func
  .word foo@PLT - (vtable+8)  // offset between PLT entry for foo and first vtable func

and the instructions for accessing the rtti object will be the same since the GOT will hold the address of vtable.rtti. vtable.rtti@GOTPCREL-4 will resolve to a R_RISCV_GOT32_PCREL reloc.

from riscv-elf-psabi-doc.

Thanks for the description. I was thinking that #402 could use a brief summary of the goal.

Using linker-managed GOT is indeed better than a manual construct.

https://maskray.me/blog/2023-02-26-linker-notes-on-power-isa

Another difference is the explicit mention of .toc. This scheme gives the compiler control within the translation unit. With the traditional GOT scheme, input files do not mention .got. The compiler does not control how the linker will layout .got. Well, I disagree with the presumed advantage of .toc: the compiler does not know the global information, and the translation unit local layout may not be ideal. A linker is better placed to do such link-time optimization.

I think another advantage introducing the data relocation is that: -shared -fpic -fexperimental-relative-c++-abi-vtables builds will not create PLT entries for functions in the vtables, as long as they are not directly called.

from riscv-elf-psabi-doc.

Is #402 address the request? If so, I gonna close this issue?

from riscv-elf-psabi-doc.

Is #402 address the request? If so, I gonna close this issue?

It does and we can close the issue now.
I am waiting on @PiJoules's AArch64 side changes of LLVMMC/lld, then the RISC-V changes should be straightforward:)

from riscv-elf-psabi-doc.