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: Linker scripts and Section Reordering.

On Tue, Jan 8, 2013 at 2:59 PM, Sriraman Tallam <> wrote:
>   Using linker scripts along with section reordering, either through
> --section-ordering-file or the plugin, can cause bugs during segment
> address computation.
>   Linker scripts fire first, in file,  function
> "relaxation_loop_body" calls function
> "set_section_addresses_from_script" and computes an output section
> address for ".text". This can also sort text input sections if
> specified via the linker script.
>    Section ordering sorting comes later and is called in a chain of
> events starting from function "set_segment_offsets" which is called
> again from function "relaxation_loop_body" in With section
> ordering sorting, the output_section size can change, considering
> alignment. If the resulting size happens to be smaller than what was
> computed earlier, we get an error  of the form "address of section
> <section-name> moves backward from XXX to YYY". This error will
> correspond to the section that follows ".text" in the linker script as
> its start address begins  where ".text" ends. This error code is
> located in file in function "set_section_list_addresses".
>    The other problem is that of handling section sorting when it is
> specified via linker scripts and section reordering. We encountered
> this problem with the kernel where we cannot do without linker
> scripts. We found that plugin based section reordering in the kernel
> improves the performance of some applications but we also wanted the
> ordering to be compatible with the linker script used.
>    To solve these problems, I propose the following simple patch. This
> patch will invoke section sorting earlier, before the linker script
> can compute the address of the output section. Then, the linker script
> can re-sort the sections and the new computed address will be correct
> as the order of sections will not change.
>   With the patch, the resulting order of input sections is definitely
> agreeable with the linker script specification. All other input
> sections which the linker script did not care about will be agreeable
> with the section ordering spec. If we make the linker script sorting
> glob generic, like specify just ".text.*"  within the sections clause,
> then we can get the sorting from section ordering alone.
> Patch attached.
>         * output.h (sort_attached_input_sections): Change to be public.
>         * (set_section_addresses): Call
> sort_attached_input_sections
>         before linker script assigns section addresses.

>    // Sort the attached input sections.
> -  void
> -  sort_attached_input_sections();
> +  // void
> +  // sort_attached_input_sections();

Remove this, don't just comment it out.

> +      if (os != NULL
> +	  && os->input_section_order_specified())
> +	os->sort_attached_input_sections();

It seems to me that this should be in
Output_section_definition::set_section_addresses.  You may need it in
Orphan_output_section::set_section_addresses but probably not.

Your patch implies that the ordering in the linker script overrides
--section-ordering-file or a plugin.  This should be documented in a
comment at least.


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