relocation truncated to fit error on alpha

relocation truncated to fit error on alpha

[Brad Lucier]

I'm trying to build deal.II CVS with gcc-3.4 on alphaev6-unknown-linux-gnu
and in trying to run the first test, I get the error messages:

============================ Linking step-1
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparse_matrix.float.g.o)(.rodata+0x2e00): relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparse_matrix.float.g.o)(.rodata+0x2e04): relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparse_matrix.float.g.o)(.rodata+0x2e08): relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparse_matrix.float.g.o)(.rodata+0x2e0c): relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparse_matrix.float.g.o)(.rodata+0x2e10): relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparse_matrix.float.g.o)(.rodata+0x2e14): relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparse_matrix.float.g.o)(.rodata+0x2e18): relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparse_matrix.float.g.o)(.rodata+0x2e1c): relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparsity_pattern.g.o):ExcInvalidIndex/source/sparsity_pattern.cc:99: relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparsity_pattern.g.o):ExcInvalidIndex/source/sparsity_pattern.cc:99: relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparsity_pattern.g.o):ExcInvalidIndex/source/sparsity_pattern.cc:99: relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparsity_pattern.g.o):ExcInvalidIndex/source/sparsity_pattern.cc:99: relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparsity_pattern.g.o):ExcInvalidIndex/source/sparsity_pattern.cc:99: relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparsity_pattern.g.o):ExcInvalidIndex/source/sparsity_pattern.cc:99: relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparsity_pattern.g.o):ExcInvalidIndex/source/sparsity_pattern.cc:99: relocation truncated to fit: GPREL32 *UND*
/export/home/lucier/programs/deal.II/lib/liblac.g.a(sparsity_pattern.g.o):ExcInvalidIndex/source/sparsity_pattern.cc:99: relocation truncated to fit: GPREL32 *UND*
collect2: ld returned 1 exit status
make[1]: *** [step-1] Error 1

Now, this is the same as PR6999, which you, Wolfgang, recently closed; it's
somewhat ironic now that it comes up again when I'm trying to use your
deal.II package.

There have been several threads about this problem in the mail lists over
the years, for example beginning at

http://gcc.gnu.org/ml/gcc/2001-09/msg00645.html

and

http://gcc.gnu.org/ml/gcc/2001-09/msg00645.html

which leads to Richard Henderson proposing a patch in

http://gcc.gnu.org/ml/gcc/2001-11/msg00413.html

which may not have been followed up.

So, does anyone have any suggestions about how to fix the build process of
deal.II (which I find somewhat opaque) or how to fix this once and for all
with gcc?

Brad

Re: relocation truncated to fit error on alpha

[Richard Henderson]

On Fri, Apr 04, 2003 at 02:15:45PM -0500, Brad Lucier wrote:
> http://gcc.gnu.org/ml/gcc/2001-09/msg00645.html

MIPS, not Alpha, and concerns GOT overflow.

> http://gcc.gnu.org/ml/gcc/2001-11/msg00413.html

Concerns branch overflow, not gprel.  And it did go in.

> /export/home/lucier/programs/deal.II/lib/liblac.g.a(sparse_matrix.float.g.o)(.rodata+0x2e00): relocation truncated to fit: GPREL32 *UND*

The thing you should be concerned about here is not the
relocation type at all, or even the overflow, but that
we're relocating against an undefined symbol.

I don't suppose you have sparse_matrix.float.g.[is] 
hanging about?


r~

Re: relocation truncated to fit error on alpha

[Wolfgang Bangerth]

> I'm trying to build deal.II CVS with gcc-3.4 on alphaev6-unknown-linux-gnu
> and in trying to run the first test, I get the error messages:
> 
> ============================ Linking step-1
> liblac.g.a(sparse_matrix.float.g.o)(.rodata+0x2e00): relocation truncated to fit: GPREL32 *UND*
> liblac.g.a(sparse_matrix.float.g.o)(.rodata+0x2e04): relocation truncated to fit: GPREL32 *UND*
> [...]
> collect2: ld returned 1 exit status
> make[1]: *** [step-1] Error 1
> 
> Now, this is the same as PR6999, which you, Wolfgang, recently closed; it's
> somewhat ironic now that it comes up again when I'm trying to use your
> deal.II package.

Indeed ironic. Sorry, then, for doing this, I closed it because there was 
no feedback for a long time.

> which leads to Richard Henderson proposing a patch in
> http://gcc.gnu.org/ml/gcc/2001-11/msg00413.html
> which may not have been followed up.

But it was checked in as version 1.202 of the config/alpha/alpha.c


> So, does anyone have any suggestions about how to fix the build process of
> deal.II (which I find somewhat opaque) or how to fix this once and for all
> with gcc?

I can't comment on the gcc side, but am of course more than willing to 
answer all questions about the build process in deal.II. By the way, the 
flags used for building are in common/Make.global_options. The ones used 
for the files above (the debug build) are in $CXXFLAGSG.

Regards
  Wolfgang (...would love to help more, if only could...)

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: relocation truncated to fit error on alpha

[Falk Hueffner]

Richard Henderson <rth@redhat.com> writes:

> > /export/home/lucier/programs/deal.II/lib/liblac.g.a(sparse_matrix.float.g.o)(.rodata+0x2e00): relocation truncated to fit: GPREL32 *UND*
> 
> The thing you should be concerned about here is not the
> relocation type at all, or even the overflow, but that
> we're relocating against an undefined symbol.
> 
> I don't suppose you have sparse_matrix.float.g.[is] 
> hanging about?

sfs fails with a similar error on Alpha
(http://buildd.debian.org/fetch.php?&pkg=sfs&ver=1%3A0.7.2-3&arch=alpha&stamp=1043589561&file=log&as=raw):

g++ -g -O2 -Wall -o .libs/sfsproac sfsauthmgr.o sfsextauth.o sfsproac.o ../sfsmisc/.libs/libsfsmisc.so -lresolv -lnsl ../svc/.libs/libsvc.so -lresolv -lnsl ../crypt/.libs/libsfscrypt.so -lresolv -lnsl ../arpc/.libs/libarpc.so -lresolv -lnsl ../async/.libs/libasync.so -lresolv -lnsl /usr/lib/libgmp.so -lresolv -lnsl -Wl,--rpath -Wl,/usr/lib/sfs-0.7.2
sfsproac.o(.rodata+0xd4):/tmp/sfs-0.7.2/async/str.h:420: relocation truncated to fit: GPREL32 *UND*
sfsproac.o(.rodata+0xd8):/tmp/sfs-0.7.2/arpc/xdrmisc.h:243: relocation truncated to fit: GPREL32 *UND*
sfsproac.o(.rodata+0xdc):/tmp/sfs-0.7.2/async/str.h:312: relocation truncated to fit: GPREL32 *UND*
sfsproac.o(.rodata+0xe0):/tmp/sfs-0.7.2/async/union.h:102: relocation truncated to fit: GPREL32 *UND*
sfsproac.o(.rodata+0xe4):/tmp/sfs-0.7.2/async/union.h:105: relocation truncated to fit: GPREL32 *UND*
sfsproac.o(.rodata+0xe8):/tmp/sfs-0.7.2/async/str.h:420: relocation truncated to fit: GPREL32 *UND*
sfsproac.o(.rodata+0xec):/tmp/sfs-0.7.2/async/str.h:180: relocation truncated to fit: GPREL32 *UND*
collect2: ld returned 1 exit status

I've put sfsproac.ii.bz2 and sfsproac.s.bz2 at
http://people.debian.org/~falk/.

-- 
	Falk

Re: relocation truncated to fit error on alpha

[Richard Henderson]

On Fri, Apr 04, 2003 at 10:39:03PM +0200, Falk Hueffner wrote:
> sfsproac.o(.rodata+0xec):/tmp/sfs-0.7.2/async/str.h:180: relocation truncated to fit: GPREL32 *UND*

Ah.  These are all of the form

00000000000000d4 GPREL32           .gnu.linkonce.t._ZN13sfsauth_dbrec8set_typeE1
4sfsauth_dbtype+0x0000000000000040

i.e. this is part of a switch statement.

My guess is that _ZN13sfsauth_dbrec8set_typeE14sfsauth_dbtype was emitted
multiple times, and this copy was dropped, which left the relocations from
the tablejump pointing to nothing.

In the short term this could be "fixed" in the linker, so that it ignores
gprel32 relocations to sections that have been removed.

The most correct fix is to use section groups, such that the bits associated
with the function get discarded with it.  This is a lot of work all the way
through the toolchain though.


r~

Re: relocation truncated to fit error on alpha

[Alan Modra]

On Fri, Apr 04, 2003 at 01:42:51PM -0800, Richard Henderson wrote:
> The most correct fix is to use section groups, such that the bits associated
> with the function get discarded with it.  This is a lot of work all the way
> through the toolchain though.

ELF SHT_GROUP support has been in binutils for a year and a half.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: relocation truncated to fit error on alpha

[Brad Lucier]

> On Fri, Apr 04, 2003 at 10:39:03PM +0200, Falk Hueffner wrote:
> > sfsproac.o(.rodata+0xec):/tmp/sfs-0.7.2/async/str.h:180: relocation truncated to fit: GPREL32 *UND*
...
> The most correct fix is to use section groups, such that the bits associated
> with the function get discarded with it.  This is a lot of work all the way
> through the toolchain though.

The same problem occurs in 3.3; I'll try to put together a proper PR tomorrow
morning.  It seems fairly serious.

Brad

Re: relocation truncated to fit error on alpha

[Richard Henderson]

On Sat, Apr 05, 2003 at 10:39:44AM +0930, Alan Modra wrote:
> ELF SHT_GROUP support has been in binutils for a year and a half.

Multiple sections with the same name still isn't supported.



r~

Re: relocation truncated to fit error on alpha

[Alan Modra]

On Sat, Apr 05, 2003 at 12:58:17AM -0800, Richard Henderson wrote:
> On Sat, Apr 05, 2003 at 10:39:44AM +0930, Alan Modra wrote:
> > ELF SHT_GROUP support has been in binutils for a year and a half.
> 
> Multiple sections with the same name still isn't supported.

Eh?  What do you need this for?  Hmm, I suppose you want to do

 .section .text,"axG",@progbits,group.1

then later in the same file

 .section .text,"axG",@progbits,group.2

and have the two ".text"s separate (and separate from the standard
.text)?  Why not just call the sections .text.1 and .text.2?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: relocation truncated to fit error on alpha

[Brad Lucier]

> 
> > On Fri, Apr 04, 2003 at 10:39:03PM +0200, Falk Hueffner wrote:
> > > sfsproac.o(.rodata+0xec):/tmp/sfs-0.7.2/async/str.h:180: relocation truncated to fit: GPREL32 *UND*
> ...
> > The most correct fix is to use section groups, such that the bits associated
> > with the function get discarded with it.  This is a lot of work all the way
> > through the toolchain though.
> 
> The same problem occurs in 3.3; I'll try to put together a proper PR tomorrow
> morning.  It seems fairly serious.

Arggh.  It doesn't work in 3.2.2, either.  Working backward on my toolchains...

Brad

Re: relocation truncated to fit error on alpha

[Brad Lucier]

I filed a proper PR for this problem as target/10326.

Brad

Re: relocation truncated to fit error on alpha

[Richard Henderson]

On Sat, Apr 05, 2003 at 09:46:26PM +0930, Alan Modra wrote:
> and have the two ".text"s separate (and separate from the standard
> .text)?

Yes.

> Why not just call the sections .text.1 and .text.2?

You don't have to have magic in the linker script to know
that they should be merged at final link time.


r~