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.
>
> You can also make the case that the code is invalid. You've created an
> invalid pointer.
>
I've cast a pointer to __UINTPTR_TYPE__, and added a constant. I've not created any pointer.
The testcase originally comes from a code that checks if the pointer is aligned.
>
>
> Jeff
>
>
Thank you,
Zdenek
