This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Patch to do reorder text and data sections according to a user specified sequence.
Hi,
I noticed weird "** fill"ing behavior while looking at mapfiles. Ian
says this is a bug, so I'm sending this to the list.
When compiling with -ffunction-sections, many sections usually have some
fill after them. I'm not sure why that's needed..but a more interesting
problem is that once you order those sections, the remaining fill gets
lumped together like this:
.rel.dyn 0x0007c21c 0x18eaf0
** dynamic relocs
0x0007c21c 0x18eaf0
.rel.plt 0x0020ad0c 0xb0d0
** dynamic relocs
0x0020ad0c 0xb0d0
.text 0x00215de0 0xb35709
** fill 0x00215de0 0xa
** fill 0x00215dea 0x1
** fill 0x00215deb 0x1
** fill 0x00215dec 0x2
** fill 0x00215dee 0x1
** fill 0x00215def 0x1
** fill 0x00215df0 0x1
** fill 0x00215df1 0x1
** fill 0x00215df2 0x1
** fill 0x00215df3 0x1
** fill 0x00215df4 0x1
** fill 0x00215df5 0x1
** fill 0x00215df6 0x2
** fill 0x00215df8 0x1
** fill 0x00215df9 0x1
** fill 0x00215dfa 0x1
** fill 0x00215dfb 0x1
** fill 0x00215dfc 0x1
** fill 0x00215dfd 0x1
** fill 0x00215dfe 0x1
** fill 0x00215dff 0x1
This keeps going, in my binary I ended up with 50K of "** fill". Before
ordering the fill found among sections like so:
.text._Z11IsSameCCMapPtS_
0x002163f6 0x43 nsCompressedCharMap.o
0x002163f6 _Z11IsSameCCMapPtS_
** fill 0x00216439 0x1
.text._ZN19nsCompressedCharMap9FillCCMapEPt
0x0021643a 0x23 nsCompressedCharMap.o
0x0021643a
_ZN19nsCompressedCharMap9FillCCMapEPt
** fill 0x0021645d 0x1
.text._ZN19nsCompressedCharMapD2Ev
0x0021645e 0x41 nsCompressedCharMap.o
0x0021645e _ZN19nsCompressedCharMapD2Ev
0x0021645e _ZN19nsCompressedCharMapD1Ev
** fill 0x0021649f 0x1
.text._ZN19nsCompressedCharMapC2Ev
0x002164a0 0x7e nsCompressedCharMap.o
0x002164a0 _ZN19nsCompressedCharMapC2Ev
0x002164a0 _ZN19nsCompressedCharMapC1Ev
.text._ZN19nsCompressedCharMap7SetCharEj
0x0021651e 0x137 nsCompressedCharMap.o
0x0021651e
_ZN19nsCompressedCharMap7SetCharEj
** fill 0x00216655 0x1
.text._ZN19nsCompressedCharMap8SetCharsEtPj
0x00216656 0x121 nsCompressedCharMap.o
0x00216656
_ZN19nsCompressedCharMap8SetCharsEtPj
** fill 0x00216777 0x1
.text._ZN19nsCompressedCharMap8SetCharsEPt
0x00216778 0x175 nsCompressedCharMap.o
0x00216778
_ZN19nsCompressedCharMap8SetCharsEPt
** fill 0x002168ed 0x1
.text._ZN19nsCompressedCharMap8SetCharsEPj
0x002168ee 0x2d nsCompressedCharMap.o
0x002168ee
_ZN19nsCompressedCharMap8SetCharsEPj
.text._Z10MapToCCMapPj
0x0021691b 0x84 nsCompressedCharMap.o
0x0021691b _Z10MapToCCMapPj
.text._Z13MapperToCCMapP20nsICharRepresentable
0x0021699f 0x45 nsCompressedCharMap.o
0x0021699f
_Z13MapperToCCMapP20nsICharRepresentable
.text._Z13MapToCCMapExtPjPS_j
0x002169e4 0x1f5 nsCompressedCharMap.o
0x002169e4 _Z13MapToCCMapExtPjPS_j
** fill 0x00216bd9 0x1
.text._ZN19nsCompressedCharMap8NewCCMapEv
0x00216bda 0x75 nsCompressedCharMap.o
0x00216bda
_ZN19nsCompressedCharMap8NewCCMapEv
** fill 0x00216c4f 0x1
On 06/03/2010 11:01 AM, Sriraman Tallam wrote:
Thanks. I committed the patch.
2010-06-03 Sriraman Tallam<tmsriram@google.com>
PR gold/11658
* output.cc
(Output_section::Input_section_sort_entry::compare_section_ordering):
Change to return non-zero correctly.
(Output_section::Input_section_sort_section_order_index_compare
::operator()): Change to fix ambiguity in comparisons.
On Thu, Jun 3, 2010 at 8:55 AM, Ian Lance Taylor<iant@google.com> wrote:
Sriraman Tallam<tmsriram@google.com> writes:
* output.cc
(Output_section::Input_section_sort_entry::compare_section_ordering):
Change to return non-zero correctly.
(Output_section::Input_section_sort_section_order_index_compare::operator()):
Change to fix ambiguity in comparisons.
This is OK.
Thanks.
Ian