[EXTERNAL] Re: [PATCH] RISC-V: Do not gp relax against an ABS symbol if it is far away.

[Joseph Faulls]

> What's the use case for using AUIPC/LW to load an absolute symbol?  Such symbols are not used in contexts where an address could alternatively be expected, so the correct sequence, and in PIC or PIE code indeed the only valid, for direct references from code is LUI/ADDI

For my clarification, are you saying that the AUIPC/LW should never have been generated? If so, how is it possible for the compiler to know that the symbol referenced will be an absolute symbol?

Regardless, that's a good point, changing all AUIPC/LW to LUI/ADDI for absolute symbols makes sense to me. I could try and do this if it's good way forward, but I would like a second opinion first! Palmer, Nelson, what are your thoughts?

-----Original Message-----
From: Maciej W. Rozycki <macro@orcam.me.uk> 
Sent: Tuesday, August 8, 2023 10:49 AM
To: Joseph Faulls <Joseph.Faulls@imgtec.com>
Cc: binutils@sourceware.org; palmer@rivosinc.com; nelson@rivosinc.com
Subject: [EXTERNAL] Re: [PATCH] RISC-V: Do not gp relax against an ABS symbol if it is far away.

On Thu, 27 Jul 2023, Joseph Faulls wrote:

> Relaxations can cause the gp to move after it has been decided to gp 
> relax. Against an absolute symbol, the distance may change such that 
> the offset can no longer fit in the 12-bit immediate field.

 What's the use case for using AUIPC/LW to load an absolute symbol?  Such symbols are not used in contexts where an address could alternatively be expected, so the correct sequence, and in PIC or PIE code indeed the only valid, for direct references from code is LUI/ADDI.  Since you're fiddling with linker relaxation code here, you may well take the opportunity and relax it to LUI/ADDI, or ADDI alone if the value is small.  There may be an issue with RV64 objects if the value turns out outside the 32-bit range though, which will be a relocation overflow.

  Maciej