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.e...@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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
