This is the mail archive of the
binutils@sourceware.org
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 [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 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.
Thanks,
Jack