[PATCH] D72959: Relative VTables ABI on Fuchsia

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

In D72959#1832011 <https://reviews.llvm.org/D72959#1832011>, @pcc wrote:

> > On Aarch64, right now only CALL26 and JUMP26 instructions generate PLT relocations, so we manifest them with stubs that are just jumps to the original function.
>
> I think it would be worth considering defining a new relocation type for this. I think we should make the new reloc type represent the relative address shifted right by 2, which would allow it to be used freely in the aarch64 small code model (which permits programs up to 4GB), but would require the target to be 4-byte aligned, which seems like a reasonable restriction. On aarch64, decoding this would not require any additional instructions either (we can fold the lsl into the add). We could use the same technique for a new GOTPCREL relocation to be used for the RTTI component. @peter.smith what do you think?


The idea of a new relocation type has come up before, as I recall it was something like the equivalent of R_X86_PLT32

  | R_X86_64_PLT32 | 4 | word32 | L + A - P |
  Where L is defined as: L Represents the place (section offset or address) of the Procedure Linkage Table entry for a symbol.

For Fuchsia there are two options:
1.) Ask for an ABI relocation type to be defined. I've raised an ABI issue with Arm, for it to progress I think it needs a "yes we really would like one, here is the definition we want to use, this is the use case and it could be used outside of Fuchsia at some point." For example I can see position independent C++ being useful in bare-metal embedded C++. The external facing email for feedback on the abi is arm.eabi at arm.com (address is on the first page of the doc below)
2.) There are two ranges of relocation types reserved for private and platform relocations: https://developer.arm.com/docs/ihi0056/f/elf-for-the-arm-64-bit-architecture-aarch64-abi-2019q2-documentation

  Private and platform-specific relocations
  Private relocations for vendor experiments:
  
  0xE000 to 0xEFFF for ELF64
  0xE0 to 0xEF for ELF32
  Platform ABI defined relocations:
  
  0xF000 to 0xFFFF for ELF64
  0xF0 to 0xFF for ELF32
  Platform ABI relocations can only be interpreted when the EI_OSABI field is set to indicate the Platform ABI governing the definition.
  
  All of the above codes will not be assigned by any future version of this standard.

If this could be generally useful outside of Fuchsia, then an official relocation would be preferable.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72959/new/

https://reviews.llvm.org/D72959