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

[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?