[PATCH] D137384: [MC][LoongArch] Fix needsRelocateWithSymbol() implementation
Jinyang He via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 8 23:31:43 PST 2022
MQ-mengqing added a comment.
In D137384#3916546 <https://reviews.llvm.org/D137384#3916546>, @tangyouling wrote:
> 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?
In D137384#3916546 <https://reviews.llvm.org/D137384#3916546>, @tangyouling wrote:
> 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?
Hi, All,
Frankly the custom implementation is more appreciated at present. Although I want to use the generic implementation but binutils cannot guarantee the user action as follows,
Code:
la.got $r0, sym
sym:
Reloc:
0000000000000000 000000010000004b R_LARCH_GOT_PC_HI20 0000000000000000 .text + 8
0000000000000004 000000010000004c R_LARCH_GOT_PC_LO12 0000000000000000 .text + 8
When sym is local, binutils-ld failed here. As relax may be added in the future, thus, I think it's appropriate to use custom implementation.
Other ideas?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D137384/new/
https://reviews.llvm.org/D137384
More information about the llvm-commits
mailing list