On Wed, 2025-07-23 at 07:47 +0200, Zdenek Sojka via Gcc-help wrote:
> Hello Jeff,
>
> thank you for the answer!
>
>
> ---------- Původní e-mail ----------
> Od: Jeff Law <jeffreyalaw@xxxxxxxxx>
> Komu: Zdenek Sojka <zsojka@xxxxxxxxx>, gcc-help@xxxxxxxxxxx
> Datum: 23. 7. 2025 6:35:53
> Předmět: Re: riscv64 -mcmodel=medany relocation truncated to fit:
> R_RISCV_PCREL_HI20 against symbol ...
>
>
> > On 7/22/25 3:58 AM, Zdenek Sojka via Gcc-help wrote:
> > > Hello,
> > >
> > > I am facing an issue during linking when building code for riscv64
> > > with gcc-15:
> > >
> > >
> > > $ cat al.c
> > > int a[1];
> > >
> > > __UINTPTR_TYPE__ foo(void)
> > > {
> > > return (__UINTPTR_TYPE__)a + 0x7fffffff;
> > > }
> > >
> > > int main() {}
> > > $ riscv64-unknown-linux-gnu-gcc-15 al.c -O -mcmodel=medany -save-
> > > temps
> > > a-al.o: in function `foo':
> > > al.c:(.text+0x0): relocation truncated to fit: R_RISCV_PCREL_HI20
> > > against symbol `a' defined in .sbss section in a-al.o
> > > collect2: error: ld returned 1 exit status
> > >
> > >
> > > this seems to be caused by relocation:
> > >
> > > $ objdump -r a-al.o
> > >
> > > a-al.o: file format elf64-littleriscv
> > >
> > > RELOCATION RECORDS FOR [.text]:
> > > OFFSET TYPE VALUE
> > > 0000000000000000 R_RISCV_PCREL_HI20 a+0x000000007fffffff
> > > 0000000000000000 R_RISCV_RELAX *ABS*+0x000000007fffffff
> > > 0000000000000004 R_RISCV_PCREL_LO12_I .L0
> > > 0000000000000004 R_RISCV_RELAX *ABS*
> > > ...
> > >
> > >
> > >
> > > Is it an issue in gcc, binutils - or in the code?
> >
> > It's not 100% clear. I could make a case that GCC shouldn't have
> > generated that code.
>
> I tried x86_64, aarch64, powerpc64, riscv64 with all -mcmodel=
> variants - this is the only one that is failing.
>
> There seems to be a related LLVM issue,
> https://github.com/llvm/llvm-project/issues/134525
>
> > But I could also make a case that given the use of
> > the lla pseudo-op that gas should have managed to handle it better.
>
> Do you mean that gas shouldn't generate R_RISCV_PCREL_HI20 relocation
> if there is an offset to the symbol?
>
> This is actually an interesting question:
> if there is a long array at the end of the reachable address range for
> given code model, is it guaranteed that any valid C pointer, based on
> that array, is also addressable in given code model?
> The symbol of the array is addressable in the given code model, but
> eg. "&array[1 << 20]" might not be.
>
> Maybe I misunderstand the documentation here: "symbol" maybe means not
> only the symbol address itself, but includes the whole range <symbol,
> symbol + symbol.size> (including both ends).
>
>
>
> I would actually agree with the comment:
>
> https://github.com/llvm/llvm-project/issues/134525#issuecomment-2784539065
>
> that implies, in my understanding: any offset to a symbol that is not
> in the range <symbol, symbol + symbol.size> cannot use the relocation
> to be generated, thus cannot use the lla pseudo-op; making it a GCC
> issue.
https://gcc.gnu.org/PR91420
--
Xi Ruoyao <xry111@xxxxxxxxxxx>
