This is the mail archive of the
mailing list for the binutils project.
RE: [MIPS] Is it legal for the assembler to generate more than 64K sections?
- From: Jack Carter <Jack dot Carter at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 3 Feb 2014 20:49:54 +0000
- Subject: RE: [MIPS] Is it legal for the assembler to generate more than 64K sections?
- Authentication-results: sourceware.org; auth=none
- References: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6F2880 at BADAG02 dot ba dot imgtec dot org> <CAMe9rOrtyAQYyzRx4AbcmtCSKMr-rzjUcHEHsCAm60j_PhP5Uw at mail dot gmail dot com> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6F2AA2 at BADAG02 dot ba dot imgtec dot org>,<87mwi87xeu dot fsf at talisman dot default>
From: Richard Sandiford [firstname.lastname@example.org]
Sent: Monday, February 03, 2014 12:29 PM
To: Jack Carter
Cc: H.J. Lu; email@example.com
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?
> 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
We have a "canadian_cross" build of LLVM and have been getting off and on link time errors from one of the input object files RecursiveASTVisitorTest.o. :
(.text._ZN4llvm25SmallVectorTemplateCommonIN5clang19RecursiveASTVisitorINS1_11AttrVisitorEE10EnqueueJobEvE4backEv[_ZN4llvm25SmallVectorTemplateCommonIN5clang19RecursiveASTVisitorINS1_11AttrVisitorEE10EnqueueJobEvE4backEv]+0x64): relocation truncated to fit: R_MIPS_GOT16 against `no symbol'
Basically building LLVM with a MIPS GCC. I noticed that the section count was 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 further. Why I never knew about this trap door for section overflow is beyond me :-| Probably since I never hit the limit myself.