Hello,
---------- Původní e-mail ----------
Od: Xi Ruoyao <xry111@xxxxxxxxxxx>
Komu: Zdenek Sojka <zsojka@xxxxxxxxx>, Jeff Law <jeffreyalaw@xxxxxxxxx>
Kopie: gcc-help@xxxxxxxxxxx
Datum: 23. 7. 2025 8:26:16
Předmět: Re: riscv64 -mcmodel=medany relocation truncated to fit: R_RISCV_PCREL_HI20 against symbol ...
> 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>
thank you for the link, but that code is not a valid C:
&"x"[2147483647] does not yield a valid pointer
Best regards,
Zdenek
