See the following test case $ cat test.c int a = 1; int main() { return a; } Building the test case with "-nostdlib" seems to disable the GP linker relaxation: $ riscv64-unknown-linux-gnu-gcc test.c -o test -nostdlib $ riscv64-unknown-linux-gnu-objdump -d test | grep gp <return nothing> But if we compile test.c without "-nostdlib": $ riscv64-unknown-linux-gnu-gcc test.c -o test $ riscv64-unknown-linux-gnu-objdump -d test | grep gp 103bc: 00002197 auipc gp,0x2 103c0: 46418193 addi gp,gp,1124 # 12820 <__global_pointer$> 1041c: 8141c783 lbu a5,-2028(gp) # 12034 <_edata> 1042a: 80f18a23 sb a5,-2028(gp) # 12034 <_edata> 10440: 8101a783 lw a5,-2032(gp) # 12030 <a> Note: this bug was previously filed in GCC bugzila, and it was suggested it should be filed against binutils. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91713
Commentary copied from the gcc bug report... This is an edge condition and an accident of circumstances. When you link with the default libraries, other stuff gets put in sdata before a, and so the variable a is in range of gp because it is at -0x7f0. When you link with -nostdlib, a is the only thing in sdata, and we run into an edge condition where a is -0x800 from gp, which is at the extreme limit, but the linker relaxation has to limit the range to deal with section alignment issues that may changes addresses after relaxation, and so we have to assume that a is out of range. If you change the example to int a = 1; int b = 2; int c = 3; int d = 4; int e = 5; int main() { return a + b + c + d + e; } then we see that all 5 variables use gp address with default libraries, and only the last 3 with -nostdlib, so we are losing the first two variables due to address range limitation at linker relaxation time. There is a somewhat related open binutils bug report https://sourceware.org/bugzilla/show_bug.cgi?id=24678 and another somewhat related binutils bug report I recently fixed https://sourceware.org/ml/binutils/2019-08/msg00244.html if gp was still computed inside the .sdata section we wouldn't have this problem, but that means undoing a change that reduced code size for most applications. Maybe there is a different way to solve the earlier problem that doesn't cause this problem.
*** Bug 24992 has been marked as a duplicate of this bug. ***
There is another related problem reported here https://github.com/riscv/riscv-gnu-toolchain/issues/497