[PATCH v2 1/5] LoongArch: Reject R_LARCH_32 from becoming a runtime reloc in ELFCLASS64

[Jinyang He]

在 2024/6/29 1:04, Fangrui Song 写道:

> On Thu, Jun 27, 2024 at 6:53 PM Jinyang He <hejinyang@loongson.cn> wrote:
>> On 2024-06-28 01:19, Xi Ruoyao wrote:
>>
>>> On Thu, 2024-06-27 at 20:39 +0800, Xi Ruoyao wrote:
>>>>> I'd like to do this rejection earlier in `check_relocs` than
>>>>> `relocate_section`. Generally loongarch32 do not produce R_LARCH_64,
>>>>> so this rejection should be efficient only for R_LARCH_32 on
>>>>> loongarch64.
>>>> Ok, in V3 I'll use the same approach as RISC-V then.
>>> And after some thinking: R_LARCH_64 on loongarch32 should be fine.  On
>>> little-endian hardware *(uint64 *)pc += load_addr should be same as
>>> *(uint32 *)pc += load_addr unless the latter wraps, but if it wraps
>>> Glibc dynamic linker should complain anyway.
>>>
>>> RISC-V also converts R_RISCV_64 to R_RISCV_RELATIVE for rv32.
>> Yes, you're right. I think we cannot avoid asm like `.8byte .L1` or
>> `.8byte .L1 - .L2`, so emiting 64bits static reloc type on loongarch32
>> makes sense.
>>
> x86-32, aarch32, ppc32, and s390 ports do not support `.quad .L1`.
> mips32 and riscv32 accept `.quad .L1`, which might be a mistake.
>
> Why cannot '.8byte .L1` be avoided?
Thank you for providing the detailed list. To be frankly, I sometimes see
how RISCV does and think how LoongArch should do. I'm sorry for lack
of in-depth thinking.

I think users may handwrite asm codes for 32-bits and 64 bits machines.
If we accept it, we can reduce the error. Users need to understand that
the value is 8 bytes as they excepted rather than the arch bits size.
Compilers such as gcc should not generate these asm codes.

If it is a clear mistake, I think we should fix it.

Thanks.