[PATCH] D18031: [lld] [ELF/AArch64] Simplify AArch64 isRelRelative

[Adhemerval Zanella via llvm-commits]

zatrazz added a comment.

In http://reviews.llvm.org/D18031#371973, @rafael wrote:

> >   bool AArch64TargetInfo::isRelRelative(uint32_t Type) const {
>
> > 
>
> > - return Type == R_AARCH64_PREL32 || Type == R_AARCH64_ADR_PREL_PG_HI21 ||
>
> > - Type == R_AARCH64_LDST8_ABS_LO12_NC ||
>
> > - Type == R_AARCH64_LDST32_ABS_LO12_NC ||
>
> > - Type == R_AARCH64_LDST64_ABS_LO12_NC ||
>
> > - Type == R_AARCH64_ADD_ABS_LO12_NC || Type == R_AARCH64_CALL26; +  switch (Type) { +  default: +    return true; +  case R_AARCH64_ABS64: +  case R_AARCH64_ADR_GOT_PAGE: +  case R_AARCH64_LD64_GOT_LO12_NC: +    return !Config->Shared;
>
>
> I don't think this makes sense. The relocations have different
>  definitions depending on -shared? If not, how come they become
>  relative or not depending on -shared?
>
> Cheers,
> Rafael


They do have different semantics depending if the code is position independent (which it is not only shared, but also PIE executables) and this method is used to define whether we will emit or not a dynamic relocation. If you check, gold is doing pretty much this in its local scan.


Repository:
  rL LLVM

http://reviews.llvm.org/D18031