linux-mips
[Top] [All Lists]

Re: linker problem: relocation truncated to fit

To: Wilbern Cobb <cobb@cn.csoft.net>
Subject: Re: linker problem: relocation truncated to fit
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Mon, 17 Sep 2001 03:50:40 +0200
Cc: "H . J . Lu" <hjl@lucon.org>, Petter Reinholdtsen <pere@hungry.com>, linux-mips@oss.sgi.com
In-reply-to: <Pine.BSO.4.33.0109161323280.14503-100000@oddbox.cn>; from cobb@cn.csoft.net on Sun, Sep 16, 2001 at 01:29:38PM -0300
References: <20010916091654.C1812@lucon.org> <Pine.BSO.4.33.0109161323280.14503-100000@oddbox.cn>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mutt/1.2.5i
On Sun, Sep 16, 2001 at 01:29:38PM -0300, Wilbern Cobb wrote:

> This is a `feature' of the MIPS toolchain. Global and static items <= n
> bytes are placed into the small data or small bss sections instead of
> the normal data or bss sections as an optimization. Excess items would
> cause these linker errors.
> 
> Pass the compiler the -Gn flag (default is 8 bytes), ie. -G4 should work
> for most purposes.

Default is -G0 because GP optimization isn't supported with SVR4 PIC code.

SVR4 code uses the $gp register as a pointer to the middle of a 64kbyte
sized data segment called GOT, global offset table.  A GOT overflow results
in obscure error messages as you observe them.

The only easy way to get around this is -Wa,-xgot and making sure that all
the static objects like libgcc which can't be rebuilt easily with -Wa,-xgot
get linked in first.  More effort is splitting files with this problem into
multiple shared libraries each below the critical size but this usually
results in better code.

The best solution which currently isn't supported by binutils is a multi-got
code model.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>