Relocation error - how to debug it ?

Relocation error - how to debug it ?

[Ravi R]

Hi,
   when linking an executable for mips, i hit this linker error:

/usr/lib/libpthread.a(pthread_create.o): In function `do_clone':
../nptl/sysdeps/pthread/createthread.c:79: relocation truncated to fit: R_MIPS_TLS_GOTTPREL against `errno'

the gcc i am using is close to:
c3.4.5-p6.mips64-octeon-linux-gcc

with the options like:
gcc -static ... -lpthread

Dunno how to go about figuring out what could be causing this problem. Any pointers/clues will be much appreciated.

thanks,
ravi


      

Re: Relocation error - how to debug it ?

[Jim Wilson]

On 04/21/2010 07:00 AM, Ravi R wrote:
>     when linking an executable for mips, i hit this linker error:
>
> /usr/lib/libpthread.a(pthread_create.o): In function `do_clone':
> ../nptl/sysdeps/pthread/createthread.c:79: relocation truncated to fit: R_MIPS_TLS_GOTTPREL against `errno'
> the gcc i am using is close to:
> c3.4.5-p6.mips64-octeon-linux-gcc
> with the options like:
> gcc -static ... -lpthread

Sounds like a bug we hit at Cisco.  I don't have all my Cisco notes 
here, but my recollection is that if you look in the file 
bfd/elfxx-mips.c in the function mips_elf_merge_gots, there is a bug in 
the setting of too_many_for_tls.  I think the failure case was when 
tcount == 0 (i.e. no new tls relocs), but the primary got already has 
tls relocs (i.e. we have old tls relocs), and the new local relocs plus 
the old tls relocs causes overflow.  The code fails to handle that case.

This bug exists in binutils-2.16 through 2.18.  It was apparently fixed 
by accident when Richard Sandiford decided that the mips reloc handling 
code needed a major rewrite.  I think that was the 2007-11-14 patch. 
His new code does not have this problem.  This is a big patch, but it is 
easy enough to fix with a small one that just fixes this one problem I 
described above.

This failure only occurs when static linking.  Most people know that you 
aren't supposed to statically link any more, which is probably why it 
went unnoticed for so long.

Jim