[PATCH] D137384: [MC][LoongArch] Fix needsRelocateWithSymbol() implementation

[Youling Tang via Phabricator via llvm-commits]

tangyouling added a comment.

In D137384#3910952 <https://reviews.llvm.org/D137384#3910952>, @MQ-mengqing wrote:

> In D137384#3907086 <https://reviews.llvm.org/D137384#3907086>, @xry111 wrote:
>
>> Hmm, BFD linker does not support `R_LARCH_GOT_PC_{HI12,LO20}` with a non-zero addend:
>>
>>   case R_LARCH_GOT_PC_HI20:
>>   case R_LARCH_GOT_HI20:
>>     /* Calc got offset.  */
>>       {
>>         unresolved_reloc = false;
>>         BFD_ASSERT (rel->r_addend == 0);
>>
>> Do we need to make a custom implementation which returns false for `R_LARCH_32_PCREL`, `R_LARCH_PCALA*`, and `R_LARCH_B*`, true for others?
>
> The procedure happens before linking. AFAIK, the way of using sec+offset is like RELA while the way of using sym is like REL (, of course it seems the REL is a subset of the RELA).
> Relocation symbols that can replace sym with sec+offset are generally local and its offset from sec can be determined at assembly procedure.
> If relax which may decrease instructions is not used, the offset would not be changed later. So it is different from the Relocation of RISCV. Replacing the sym with sec+offset effectively reduces the number of syms.
> The GOT method is used to access global symbols mostly, can they enter this function?

Yes, it happens before linking.

I found that only `R_LARCH_32`, `R_LARCH_64`, ` R_LARCH_32_PCREL`, `R_LARCH_PCALA*`, and `R_LARCH_B*` enter the function at compile time (some others like GOT don't enter it).
Modified it to the following, which also passed the test (when testing asan),

  bool needsRelocateWithSymbol(const MCSymbol &Sym,
                               unsigned Type) const override {
    switch (Type) {
    default:
      return true;
  
    case ELF::R_LARCH_32:
    case ELF::R_LARCH_64:
    case ELF::R_LARCH_B16:
    case ELF::R_LARCH_B21:
    case ELF::R_LARCH_B26:
    case ELF::R_LARCH_PCALA_HI20:
    case ELF::R_LARCH_PCALA_LO12:
    case ELF::R_LARCH_PCALA64_LO20:
    case ELF::R_LARCH_PCALA64_HI12:
    case ELF::R_LARCH_32_PCREL:
      return false;
    }
  }

Which do you think is more acceptable, using a generic implementation or using a custom implementation?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137384