bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/24983] RISC-V GP linker relaxation is not performed with -nostdl


From: wilson at gcc dot gnu.org
Subject: [Bug ld/24983] RISC-V GP linker relaxation is not performed with -nostdlib
Date: Tue, 10 Sep 2019 18:25:26 +0000

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]