Re: linker problem: relocation truncated to fit

Re: linker problem: relocation truncated to fit

[H . J . Lu]

On Sun, Sep 16, 2001 at 03:38:57PM -0700, Ryan Murray wrote:
> On Mon, Sep 17, 2001 at 12:07:19AM +0200, Petter Reinholdtsen wrote:
> > [Wilbern Cobb]
> > > 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.
> > 
> > I tried -G4, -G2 and -G1 without any luck.  Even with -G1 there are still
> 
> I don't think -G is the problem here.  The problem is that the GOT
> needs to be bigger than a 16 bit value.  The only way to do this is to
> recompile everything that is going to be linked in statically
> (libc_noshared.a and libgcc.a included) with -Wa,-xgot This problem
> currently affects openh323 and mozilla, among other things.
> 

I don't think mips is the only platform which has this problem. Do
Alpha, PowerPC and Sparc have similar problems like that? What are
the solutions for them?

BTW, it sounds like the -fpic vs. -fPIC issue. 


H.J.

Re: linker problem: relocation truncated to fit

[Ralf Baechle]

On Sun, Sep 16, 2001 at 03:50:03PM -0700, H . J . Lu wrote:

> I don't think mips is the only platform which has this problem. Do
> Alpha, PowerPC and Sparc have similar problems like that? What are
> the solutions for them?
> 
> BTW, it sounds like the -fpic vs. -fPIC issue. 

It is.  Yet I wouldn't like to assign a different meaning to -fpic and
-fPIC as most makefiles make little difference between these two options,
so that would imply quite some overhead.

  Ralf

Re: linker problem: relocation truncated to fit

[Richard Henderson]

On Mon, Sep 17, 2001 at 03:55:09AM +0200, Ralf Baechle wrote:
> It is.  Yet I wouldn't like to assign a different meaning to -fpic and
> -fPIC as most makefiles make little difference between these two options,
> so that would imply quite some overhead.

There is already such a difference.  Sparc uses 13-bit GOT offsets
with -fpic and 32-bit offsets with -fPIC.  I'm considering changes
to Alpha to use a 16/32 split for pic/PIC.


r~

Re: linker problem: relocation truncated to fit

[H . J . Lu]

On Mon, Sep 17, 2001 at 03:40:01PM -0700, Richard Henderson wrote:
> On Mon, Sep 17, 2001 at 03:55:09AM +0200, Ralf Baechle wrote:
> > It is.  Yet I wouldn't like to assign a different meaning to -fpic and
> > -fPIC as most makefiles make little difference between these two options,
> > so that would imply quite some overhead.
> 
> There is already such a difference.  Sparc uses 13-bit GOT offsets
> with -fpic and 32-bit offsets with -fPIC.  I'm considering changes
> to Alpha to use a 16/32 split for pic/PIC.

Can you mix object files compiled with -fPIC/-fpic on Sparc/Alpha?


H.J.

Re: linker problem: relocation truncated to fit

[Richard Henderson]

On Mon, Sep 17, 2001 at 03:53:25PM -0700, H . J . Lu wrote:
> Can you mix object files compiled with -fPIC/-fpic on Sparc/Alpha?

Yes, but of course the total GOT/small data area is constrained
by the size allowed by -fpic.


r~

Re: linker problem: relocation truncated to fit

[H . J . Lu]

On Mon, Sep 17, 2001 at 03:56:16PM -0700, Richard Henderson wrote:
> On Mon, Sep 17, 2001 at 03:53:25PM -0700, H . J . Lu wrote:
> > Can you mix object files compiled with -fPIC/-fpic on Sparc/Alpha?
> 
> Yes, but of course the total GOT/small data area is constrained
> by the size allowed by -fpic.

It doesn't help much if you do need -fPIC on some Qt code. Since I
don't use Qt on mips, I will let others work on it.


H.J.

Re: linker problem: relocation truncated to fit

[Jakub Jelinek]

On Mon, Sep 17, 2001 at 03:53:25PM -0700, H . J . Lu wrote:
> Can you mix object files compiled with -fPIC/-fpic on Sparc/Alpha?

At least on the Sparc, you can mix them as you want, if you don't
overflow the signed 13bit relocs in -fpic objects. The linker will tell
you...

	Jakub

Re: linker problem: relocation truncated to fit

[Jakub Jelinek]

On Tue, Sep 18, 2001 at 10:02:35AM -0700, Richard Henderson wrote:
> On Tue, Sep 18, 2001 at 03:32:33PM +0200, Marc Espie wrote:
> > The next step would be to try and reorder relocations so that the
> > -fpic stuff is nearer the GOT. Then the -fPIC stuff can overflow
> > without harming the -fpic part.
> > 
> > Of course, I haven't checked the gnu linker recently. Maybe it already
> > implements that ?
> 
> Nope.

Nope, but it wouldn't be hard to add it if people think this is common
situation. It would probably require sparc elf_link_hash_table to keep track
on how many got entries are of which type, got.offset resp.
local_got_offsets could be assigned e.g. values | 2 for
GOT{10,22} relocs and they'd be translated once got was finalized.

	Jakub

Re: linker problem: relocation truncated to fit

[Marc Espie]

On Tue, Sep 18, 2001 at 01:15:16PM -0400, Jakub Jelinek wrote:
> On Tue, Sep 18, 2001 at 10:02:35AM -0700, Richard Henderson wrote:
> > On Tue, Sep 18, 2001 at 03:32:33PM +0200, Marc Espie wrote:
> > > The next step would be to try and reorder relocations so that the
> > > -fpic stuff is nearer the GOT. Then the -fPIC stuff can overflow
> > > without harming the -fpic part.

> > > Of course, I haven't checked the gnu linker recently. Maybe it already
> > > implements that ?

> Nope, but it wouldn't be hard to add it if people think this is common
> situation. It would probably require sparc elf_link_hash_table to keep track
> on how many got entries are of which type, got.offset resp.
> local_got_offsets could be assigned e.g. values | 2 for
> GOT{10,22} relocs and they'd be translated once got was finalized.

This could be fairly useful. For instance, you may wish to have a very common
part of a library compiled with -fpic, and the rest with -fPIC.

Re: linker problem: relocation truncated to fit

[Richard Henderson]

On Sun, Sep 16, 2001 at 03:50:03PM -0700, H . J . Lu wrote:
> I don't think mips is the only platform which has this problem. Do
> Alpha, PowerPC and Sparc have similar problems like that? What are
> the solutions for them?

Alpha has a complicated scheme by which every input object file may
be assigned to a different GOT, each of which is limited to 64k.  The
other reason this works is that variables assigned to .sdata/.sbss 
are _not_ treated differently wrt code generation.  Instead, this is
optimized via linker relaxation.

IA-64 will overflow its small data area at 22 bits.

PowerPC and Sparc do not use .sdata/.sbss.


r~

Re: linker problem: relocation truncated to fit

[Jakub Jelinek]

On Mon, Sep 17, 2001 at 03:47:54PM -0700, Richard Henderson wrote:
> PowerPC and Sparc do not use .sdata/.sbss.

Minor correction: PowerPC uses .sdata/.sbss, Sparc does not.

	Jakub

Re: linker problem: relocation truncated to fit

[Geoff Keating]

> Date: Mon, 17 Sep 2001 15:47:54 -0700
> From: Richard Henderson <rth@redhat.com>
> Cc: Ryan Murray <rmurray@cyberhqz.com>, linux-mips@oss.sgi.com,
>         binutils@sourceware.cygnus.com, gcc@gcc.gnu.org

> On Sun, Sep 16, 2001 at 03:50:03PM -0700, H . J . Lu wrote:
> > I don't think mips is the only platform which has this problem. Do
> > Alpha, PowerPC and Sparc have similar problems like that? What are
> > the solutions for them?
> 
> Alpha has a complicated scheme by which every input object file may
> be assigned to a different GOT, each of which is limited to 64k.  The
> other reason this works is that variables assigned to .sdata/.sbss 
> are _not_ treated differently wrt code generation.  Instead, this is
> optimized via linker relaxation.
> 
> IA-64 will overflow its small data area at 22 bits.
> 
> PowerPC and Sparc do not use .sdata/.sbss.

Actually, powerpc could use .sdata/.sbss for shared libraries, but it
never got implemented, and it would have the disadvantage that such
code can't be linked into non-shared objects.

It would be a significant speed/space win for certain objects, most
notably libm.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: linker problem: relocation truncated to fit

[Erik Corry]

On Sun, Sep 16, 2001 at 03:50:03PM -0700, H . J . Lu wrote:
> > 
> > I don't think -G is the problem here.  The problem is that the GOT
> > needs to be bigger than a 16 bit value.  The only way to do this is to
> > recompile everything that is going to be linked in statically
> > (libc_noshared.a and libgcc.a included) with -Wa,-xgot This problem
> > currently affects openh323 and mozilla, among other things.

I think the current favoured solution on IRIX is multigot, where
if I understand correctly you switch GOT on some function calls 
in order to have multiple GOTs in one .o (or .so).

-- 
Erik Corry erik@arbat.com