Summary: | RISC-V GP linker relaxation is not performed with -nostdlib | ||
---|---|---|---|
Product: | binutils | Reporter: | Bin Meng <bmeng.cn> |
Component: | ld | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | NEW --- | ||
Severity: | normal | CC: | pinskia, wilson, yitingwang16 |
Priority: | P2 | ||
Version: | 2.30 | ||
Target Milestone: | --- | ||
See Also: |
https://sourceware.org/bugzilla/show_bug.cgi?id=29509 https://github.com/riscv-collab/riscv-gnu-toolchain/issues/497 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91713 https://sourceware.org/bugzilla/show_bug.cgi?id=24678 |
||
Host: | Target: | ||
Build: | Last reconfirmed: | 2019-09-10 00:00:00 |
Description
Bin Meng
2019-09-10 05:07:54 UTC
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 |