This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Linker scripts and Section Reordering.
- From: Ian Lance Taylor <iant at google dot com>
- To: Sriraman Tallam <tmsriram at google dot com>
- Cc: binutils <binutils at sourceware dot org>, Cary Coutant <ccoutant at google dot com>, Rong Xu <xur at google dot com>
- Date: Wed, 9 Jan 2013 07:46:05 -0800
- Subject: Re: Linker scripts and Section Reordering.
- References: <CAAs8Hmxov5mgqBpFycfdqYBTaJWS0udsn8RB9t-qcTXm5SwA3A@mail.gmail.com>
On Tue, Jan 8, 2013 at 2:59 PM, Sriraman Tallam <tmsriram@google.com> 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 layout.cc, 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 layout.cc. 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 output.cc 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.
> * script-sections.cc (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.
Ian