[PATCH] D63121: [ELF] Make the rule to create relative relocations in a writable section stricter

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

Was difficult to spot what was wrong with the bot as there were lots of commits and a non specific error message.

I'll have a think to see if there are any other relocation types besides R_ARM_TARGET1 that LLD supports that can be made into a R_ARM_RELATIVE. I don't know PPC very well unfortunately. The other case I thought of that could be difficult is ILP32, where even on something like X86_64, or AArch64 the symbolic rel for a pointer would be the 32-bit relocation. I know LLD doesn't support the AArch64 ILP32 so this isn't a problem right now.

In theory R_ARM_TARGET2 (references to TypeInfo in read-only exception handling tables) can be made into an alias for R_ARM_ABS32 with Target2Policy::Abs (--target2=abs). That option is intended for embedded systems without dynamic linking (the default is to treat it as R_ARM_GOT_PREL). So in theory it is possible, although unlikely and would arguably be better triggering an Error message if it were used.

The R_ARM_TARGET1 is a result of Arm's embedded past where there were several toolchains with subtly different ABIs, when it came to defining the official ABI there were some implementation defined points. In one environment the libraries static initialisation code used offsets to the initialization function, in another it used absolute addresses of the initialization function, the R_ARM_TARGET1 permitted a compiler to support both choices as the linker could choose depending . For Linux R_ARM_TARGET1 is essentially an alias for R_ARM_ABS32.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63121