https://sourceware.org/bugzilla/show_bug.cgi?id=24983
Jim Wilson <wilson at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-09-10
CC| |wilson at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> ---
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
