From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11318 invoked by alias); 3 Feb 2014 20:51:19 -0000 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 Received: (qmail 11309 invoked by uid 89); 3 Feb 2014 20:51:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_40,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: multi.imgtec.com Received: from multi.imgtec.com (HELO multi.imgtec.com) (194.200.65.239) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 03 Feb 2014 20:51:17 +0000 From: Jack Carter To: Richard Sandiford CC: "H.J. Lu" , "binutils@sourceware.org" Subject: RE: [MIPS] Is it legal for the assembler to generate more than 64K sections? Date: Mon, 03 Feb 2014 20:51:00 -0000 Message-ID: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6F2B73@BADAG02.ba.imgtec.org> References: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6F2880@BADAG02.ba.imgtec.org> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6F2AA2@BADAG02.ba.imgtec.org>,<87mwi87xeu.fsf@talisman.default> In-Reply-To: <87mwi87xeu.fsf@talisman.default> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SEF-Processed: 7_3_0_01192__2014_02_03_20_51_14 X-SW-Source: 2014-02/txt/msg00019.txt.bz2 ________________________________________ From: Richard Sandiford [rdsandiford@googlemail.com] Sent: Monday, February 03, 2014 12:29 PM To: Jack Carter Cc: H.J. Lu; binutils@sourceware.org Subject: Re: [MIPS] Is it legal for the assembler to generate more than 64K= sections? >> >> Does this mean everywhere in binutils and glibc for MIPS that there is a >> data structure that could store a section index that it needs to be >> increased to 32 bits? > >See: > > http://www.sco.com/developers/gabi/latest/ch4.eheader.html > >specifically: > >e_shnum > This member holds the number of entries in the section header > table. Thus the product of e_shentsize and e_shnum gives the section > header table's size in bytes. If a file has no section header table, > e_shnum holds the value zero. > > If the number of sections is greater than or equal to SHN_LORESERVE > (0xff00), this member has the value zero and the actual number of > section header table entries is contained in the sh_size field of > the section header at index 0. (Otherwise, the sh_size member of the > initial entry contains 0.) > >What's the problem you're seeing exactly? I wasn't sure from your >original message. > >Thanks, >Richard We have a "canadian_cross" build of LLVM and have been getting off and on l= ink time errors from one of the input object files RecursiveASTVisitorTest.= o. : (.text._ZN4llvm25SmallVectorTemplateCommonIN5clang19RecursiveASTVisitorINS1= _11AttrVisitorEE10EnqueueJobEvE4backEv[_ZN4llvm25SmallVectorTemplateCommonI= N5clang19RecursiveASTVisitorINS1_11AttrVisitorEE10EnqueueJobEvE4backEv]+0x6= 4): relocation truncated to fit: R_MIPS_GOT16 against `no symbol' Basically building LLVM with a MIPS GCC. I noticed that the section count w= as way above 16 bits and seized on that as being the culprit. >From the information you and H.J. have pointed me to, I need to dig furthe= r. Why I never knew about this trap door for section overflow is beyond me = :-| Probably since I never hit the limit myself. Thanks, Jack