R_RISCV_CALL vs R_RISCV_CALL_PLT about riscv-elf-psabi-doc HOT 10 CLOSED

We can't drop support for R_RISCV_CALL as the ABI was fixed when we upstreamed glibc.

We could perhaps prefer R_RISCV_CALL_PLT and deprecate R_RISCV_CALL in future toolchains. However, this isn't a bug fix, this is an enhancement. As a practical matter, we only have one person supporting the entire toolchain, so there is no time available to do enhancement work like this. There is only time available to fix stuff that is broken. Perhaps at some point in the future we will have people available to look at issues like this.

from riscv-elf-psabi-doc.

from riscv-elf-psabi-doc.

@aswaterman Such optimizations can be applied on R_RISCV_CALL_PLT, too (i386 x86-64 ppc{32,64} have similar optimizations). The preemptability is the property of the symbol, not the property of the relocation type. The evolution from powerpc ELFv1 to ELFv2 told me people did intend to assign such semantics to relocation types, but they found the semantics may be better handled on the symbol side.

from riscv-elf-psabi-doc.

call foo always gives R_RISCV_CALL; if you want R_RISCV_CALL_PLT you have to write call foo@plt.

from riscv-elf-psabi-doc.

I too see no justification for the distinction. It makes sense only on targets where there's a special ABI for calling into the PLT (typically, a register that must contain the GOT address, e.g. ebx on i386), in which case call points that aren't explicitly calling foo@PLT cannot be directed into a PLT thunk (a proper one - not an issue for the canonical non-PIC PLT thunk in a non-PIE main executable), and must be a link error (or a textrel) if the symbol is not locally defined.

from riscv-elf-psabi-doc.

@jrtc27 Sorry I made a mistake. I've changed the first sentence to use a C example instead.

from riscv-elf-psabi-doc.

I too see no justification for the distinction. It makes sense only on targets where there's a special ABI for calling into the PLT (typically, a register that must contain the GOT address, e.g. ebx on i386), in which case call points that aren't explicitly calling foo@PLT cannot be directed into a PLT thunk (a proper one - not an issue for the canonical non-PIC PLT thunk in a non-PIE main executable), and must be a link error (or a textrel) if the symbol is not locally defined.

Sometimes it's useful to ensure this specific call cannot be pre-empted. The FreeBSD libc at least makes use of this; you can work around the issue by defining a local symbol alias, but not distinguishing between call foo and call foo@plt would break this.

from riscv-elf-psabi-doc.

The RISC-V glibc port relies on the same property @jrtc27 mentioned.

from riscv-elf-psabi-doc.

Also I suppose a reason for the compiler not to emit call foo@plt with -fno-PIC is that it may have performed optimisations on the assumption that foo cannot be preempted, which is no longer true if you link it as a shared library (and that may well link just fine, especially if you used -fPIE and aren't using global non-static variables).

from riscv-elf-psabi-doc.

The undef weak check is to prevent relocation truncated errors when you call a weak function that does not get defined, and your code is compiled for an address above 0x80000000 on a 64-bit target. For an undefined weak function, we need to make the target address 0. But this is a pc-relative reloc, which has a 2GB range (medlow/medany) which means we can't actually reach 0 from any address above 0x80000000. So we detect this case and rewrite the instruction and reloc to be x0 relative instead of pc-relative, and then we can resolve the reloc without error as address 0 is reachable from x0. There are testcases for this in the ld testsuite, see for instance ld/testsuite/ld-riscv-elf/weakref*.

As a practical matter, since all linux code is compiled for a base address of 0, this only get triggered by embedded developers, so we only needed a fix for R_RISCV_CALL.

from riscv-elf-psabi-doc.