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

[Xi Ruoyao]

On Sat, 2024-06-29 at 21:56 +0800, Jinyang He wrote:
> 在 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.

For supporting this IMO we should add more functionalities like

ld.p/st.p/ldptr.p/stptr.p/addi.p/add.p/sub.p

which is assembled to ld.d etc. for lp64, and ld.w etc. for ilp32.  Now
every project is defining a bunch of macros for these, and IMO it's
better to just support them in GAS so new projects won't need to define
their own macros anymore.

And similarly, for hard coding a pointer to x we can also add a
directive like ".ptr x", which behaves like ".4byte x" for ilp32 and
".8byte x" for lp64.

I'm modifying my code to "do things RISC-V is doing" for now.  When we
finalize ilp32 support we can revise.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University