Patch to do reorder text and data sections according to a user specified sequence.

Taras Glek
Wed Jun 30 22:31:00 GMT 2010

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:
                 0x002163f6       0x43 nsCompressedCharMap.o
                 0x002163f6                _Z11IsSameCCMapPtS_
  ** fill        0x00216439        0x1
                 0x0021643a       0x23 nsCompressedCharMap.o
  ** fill        0x0021645d        0x1
                 0x0021645e       0x41 nsCompressedCharMap.o
                 0x0021645e                _ZN19nsCompressedCharMapD2Ev
                 0x0021645e                _ZN19nsCompressedCharMapD1Ev
  ** fill        0x0021649f        0x1
                 0x002164a0       0x7e nsCompressedCharMap.o
                 0x002164a0                _ZN19nsCompressedCharMapC2Ev
                 0x002164a0                _ZN19nsCompressedCharMapC1Ev
                 0x0021651e      0x137 nsCompressedCharMap.o
  ** fill        0x00216655        0x1
                 0x00216656      0x121 nsCompressedCharMap.o
  ** fill        0x00216777        0x1
                 0x00216778      0x175 nsCompressedCharMap.o
  ** fill        0x002168ed        0x1
                 0x002168ee       0x2d nsCompressedCharMap.o
                 0x0021691b       0x84 nsCompressedCharMap.o
                 0x0021691b                _Z10MapToCCMapPj
                 0x0021699f       0x45 nsCompressedCharMap.o
                 0x002169e4      0x1f5 nsCompressedCharMap.o
                 0x002169e4                _Z13MapToCCMapExtPjPS_j
  ** fill        0x00216bd9        0x1
                 0x00216bda       0x75 nsCompressedCharMap.o
  ** fill        0x00216c4f        0x1

On 06/03/2010 11:01 AM, Sriraman Tallam wrote:
> Thanks. I committed the patch.
> 2010-06-03  Sriraman Tallam<>
> 	PR gold/11658
> 	*
> 	(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<>  wrote:
>> Sriraman Tallam<>  writes:
>>>        *
>>>        (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

More information about the Binutils mailing list