From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25843 invoked by alias); 23 Apr 2010 22:20:18 -0000 Received: (qmail 25834 invoked by uid 22791); 23 Apr 2010 22:20:17 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Apr 2010 22:20:12 +0000 Received: (qmail 26609 invoked from network); 23 Apr 2010 22:20:10 -0000 Received: from unknown (HELO ?192.168.2.100?) (wilson@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Apr 2010 22:20:10 -0000 Message-ID: <4BD21D18.4070405@codesourcery.com> Date: Fri, 23 Apr 2010 22:20:00 -0000 From: Jim Wilson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc11 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ravi R CC: binutils@sourceware.org Subject: Re: Relocation error - how to debug it ? References: <134404.14597.qm@web53705.mail.re2.yahoo.com> In-Reply-To: <134404.14597.qm@web53705.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00389.txt.bz2 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