This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gold] enable sorting of text sections with the same prefix

On Tue, Feb 12, 2013 at 10:22 AM, Sriraman Tallam <> wrote:
> On Tue, Feb 12, 2013 at 9:21 AM, Ian Lance Taylor <> wrote:
>> On Tue, Feb 12, 2013 at 7:01 AM, Alexander Ivchenko <> wrote:
>>> 2013/2/9 Ian Lance Taylor <>:
>>>> On Fri, Feb 8, 2013 at 5:11 PM, Ian Lance Taylor <> wrote:
>>>>> On Thu, Feb 7, 2013 at 3:56 AM, Alexander Ivchenko <> wrote:
>>>>>> thank you for your help, Sri. I fixed help string and deleted warning.
>>>>>> Ian, could you please take a look at the attached patch?
>>>>> As far as I can see, with this patch, when you use
>>>>> --sort-section=name, gold will only sort sections that start with
>>>>> .data. and .bss. by name.  Other sections remain unsorted.  This does
>>>>> not appear to be what the GNU linker does.  The GNU linker appears to
>>>>> sort all input sections by name when using --sort-section=name.
>>>> Sorry, I guess that's not quite right.  You call the sorting code one
>>>> every section.  But you only set must_sort_attached_input_sections on
>>>> the .data and .bss sections.  How can you get away with that?
>>>> Ian
>>> You mean from hardcoding those names (.bss and .data) there? I'm not
>>> sure so far,
>>> but I know that BFD sorts them by name when we have -sort-section=name
>>> and at the
>>> same time, BFD doesn't sort, say,.sdata and .sbss.
>>> Do we need to fully mimic the behavior of BFD for this option?
>> We do not need to fully mimic GNU ld.  However, we need to understand
>> how and why GNU ld behaves the way it does.  When I look at the GNU ld
>> code, I don't see anything that restricts the effect of
>> --sort-section=name to the .data and .bss sections.  Nor is it
>> documented to behave that way.
>> The documentation of --sort-section=name for GNU ld is unfortunately
>> tied to the notion of a default linker script, which gold does not
>> share.  Still, we ought to be able to come up with some plausible
>> meaning for gold.  And restricting the behaviour to .data and .bss
>> does not make sense to me.
> Why not sort all output sections when --sort-section=name is
> specified? However, for special output sections like ctors, dtors,
> init_array, fini_array, etc. the original sort compare function will
> be used. For all other sections, use the new sort compare can be used.
> No need to hard code any names.
>> Also, in order for this to work correctly, you must call
>> set_may_sort_attached_input_sections when you create the output
>> section.  You aren't doing that, and I'm surprised that your code is
>> working reliably.
> I missed this part completely when I was reviewing his code, sorry!. I
> am not surprised his patch works for ".text" because the input
> sections are retained as he can piggy back on default text sorting.
> But, how does his test pass for bss and data? I will apply his patch
> and find out.

I figured out how input sections are kept for some ".data" sections.
When the first object is seen, the isecn entries for its .data and
.bss are not kept. But after the first object, Layout::layout is
called which sets must_sort for .data and .bss. From then on, .data
and .bss are saved. This is definitely wrong. Infact, this patch does
not work correctly on the test case included and produces an assert in when I tried it. This is because some input section
entries have isecn and some do not. We encountered an instance of this
problem earlier with the text reordering patch.

This can be fixed by removing the lines which set_must_sort in
Layout::layout and simply set_must_sort to all output sections in
Layout::make_output_section. Please note that setting may_sort and
then must_sort later is not necessary here since we know for sure that
we are going to sort this.

I have modified this patch accordingly and attached a new patch that
sorts all output sections by name when --sort-section=name is passed.
For special output sections like .ctors, it will still use the
original sort compare function. I have not special cased if for
".data" and ".bss" but I am not sure if ".sdata" and ".sbss" must be


> Sri
>> Ian

Attachment: section_sorting_name.txt
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]