Binutils-2.35 relocation truncated to fit: R_RISCV_HI20

[galak]

When building test app for riscv64 in Zephyr:

tests/application_development/libcxx

I get the following, this is use master branch of riscv-toolchain.

/opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-fputc.o): in function `.L8':
fputc.c:(.text+0x34): relocation truncated to fit: R_RISCV_HI20 against symbol `_impure_ptr' defined in .sdata section in /opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-impure.o)
/opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-fputs.o): in function `.L9':
fputs.c:(.text+0x64): relocation truncated to fit: R_RISCV_HI20 against symbol `_impure_ptr' defined in .sdata section in /opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-impure.o)
/opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-malloc.o): in function `malloc':
malloc.c:(.text+0x0): relocation truncated to fit: R_RISCV_HI20 against symbol `_impure_ptr' defined in .sdata section in /opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-impure.o)
/opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-mallocr.o): in function `_malloc_r':
mallocr.c:(.text+0x3c): relocation truncated to fit: R_RISCV_HI20 against symbol `__malloc_av_' defined in .data section in /opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-mallocr.o)
/opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-putc.o): in function `.L5':
putc.c:(.text+0x5e): relocation truncated to fit: R_RISCV_HI20 against symbol `_impure_ptr' defined in .sdata section in /opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-impure.o)
/opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-realloc.o): in function `realloc':
realloc.c:(.text+0x0): relocation truncated to fit: R_RISCV_HI20 against symbol `_impure_ptr' defined in .sdata section in /opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-impure.o)
/opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-reallocr.o): in function `.L5':
mallocr.c:(.text+0x56): relocation truncated to fit: R_RISCV_HI20 against symbol `__malloc_av_' defined in .data section in /opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-mallocr.o)
/opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-sbrkr.o): in function `_sbrk_r':
sbrkr.c:(.text+0x8): relocation truncated to fit: R_RISCV_HI20 against symbol `errno' defined in .sbss section in /opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-reent.o)
/opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-signal.o): in function `.L44':
signal.c:(.text+0x1a8): relocation truncated to fit: R_RISCV_HI20 against symbol `_impure_ptr' defined in .sdata section in /opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-impure.o)
/opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-signalr.o): in function `_kill_r':
signalr.c:(.text+0xa): relocation truncated to fit: R_RISCV_HI20 against symbol `errno' defined in .sbss section in /opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-reent.o)
/opt/riscv/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-sprintf.o): in function `_sprintf_r':
sprintf.c:(.text+0x44): additional relocation overflows omitted from the output

[Nelson1225]

In generally, R_RISCV_HI20 and R_RISCV_LO12_I/S pattern can only cover the absolute 32-bit address in the rv64 toolchain (since the signed extension, so the range will be a little bit hard to calculate).

I believe this is the code model issue. You can try to set the gcc option "-mcmodel=medany" first, and see if the problem is resolved or not. The medany model will use pc-relative relocation to access the symbols rather then use the absolutely access. Therefore, the access range should be more flexible.

[galak]

@Nelson1225 the test is already setting -mcmodel=medany and running into this issue. Using an older toolchain doesn't have issues building & linking the code.

[aswaterman]

Looks like the C library wasn’t compiled with -mcmodel=medany.

On Tue, Sep 15, 2020 at 4:36 AM Kumar Gala notifications@github.com wrote:

@Nelson1225 https://github.com/Nelson1225 the test is already setting -mcmodel=medany and running into this issue. Using an older toolchain doesn't have issues building & linking the code.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-binutils-gdb/issues/232#issuecomment-692658113, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH3XQTUSHKUZHJHVBTTFRDSF5GVPANCNFSM4RMB7QCQ .

[galak]

Looks like the C library wasn’t compiled with -mcmodel=medany.

Curious if something has changed that requires this now. Had a toolchain based on gcc-9.x and binutils-2.32 that didn't require this.

[galak]

Curious if something has changed that requires this now. Had a toolchain based on gcc-9.x and binutils-2.32 that didn't require this.

Would also appreciate @kito-cheng and @jim-wilson feelings on this as we don't seem to default -mcmodel=medany in riscv-gnu-toolchain

[jim-wilson]

There is no single way to build a toolchain that is correct for everyone. So the defaults will always be wrong no matter what the defaults are. I think arguing about default values is pointless.

SiFive builds its embedded toolchains with -mcmodel=medany and --enable-multilib, but that isn't correct for everyone.

Nothing has changed in the toolchain. Perhaps something changed in zephy, or perhaps your zephyr target changed, since whether medlow works depends on your hardware target.

[galak]

Hmm, the hardware target is qemu and the configuration w/regards to memory, etc hasn't changed.

Is it possible that newlib build with medlow and zephyr build with medany be an issue now?