This is the mail archive of the binutils@sourceware.org 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: [PATCHv2 1/3] ld: Orphan section documentation


On Wed, Mar 08, 2017 at 09:12:37PM +0000, Andrew Burgess wrote:
> Make more explicit mention of the fact that orphan sections can cause a
> new output section to be created.  Though this information is clearly
> implied in the manual it might not be clear enough.
> 
> A user _might_ (incorrectly) think that orphan sections can only be
> inserted into an existing output section.
> 
> ld/ChangeLog:
> 
> 	* ld.texinfo (Orphan Sections): Add more detail.
> ---
>  ld/ld.texinfo | 26 ++++++++++++++++++++------
>  1 file changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/ld/ld.texinfo b/ld/ld.texinfo
> index b128451..1abc9a7 100644
> --- a/ld/ld.texinfo
> +++ b/ld/ld.texinfo
> @@ -5762,12 +5762,26 @@
>  Orphan sections are sections present in the input files which
>  are not explicitly placed into the output file by the linker
>  script.  The linker will still copy these sections into the
> -output file, but it has to guess as to where they should be
> -placed.  The linker uses a simple heuristic to do this.  It
> -attempts to place orphan sections after non-orphan sections of the
> -same attribute, such as code vs data, loadable vs non-loadable, etc.
> -If there is not enough room to do this then it places
> -at the end of the file.
> +output file by either finding, or creating a suitable output section
> +in which to place the orphaned input section.
> +
> +If the name of an orphaned input section exactly matches the name of
> +an existing output section, then the orphaned input section will be
> +placed at the end of that output section.
> +
> +If there is no output section with a matching name then new output
> +sections will be created.  Each new output section will have the same
> +name as the orphan section placed within it.  If there are multiple
> +orphan sections with the same name, these will all be combined into
> +one new output section.
> +
> +If new output sections are created to hold orphaned input sections,
> +then the linker must decide where to place these new output sections
> +in relation to existing output sections.  The linker uses a simple
> +heuristic to do this.  It attempts to place orphan sections after
> +non-orphan sections of the same attribute, such as code vs data,

Not a problem with doc you've added, but please delete "non-orphan"
here.  An orphan may well be placed after another orphan of the same
attribute.

> +loadable vs non-loadable, etc.  If there is not enough room to do this
> +then it places at the end of the file.

The last sentence here is bogus too.  What does room have to do with
it?  Maybe "If no sections with matching attributes are found, the
orphan section is placed at the end of the file."

Otherwise looks good.  Please apply.

>  For ELF targets, the attribute of the section includes section type as
>  well as section flag.

-- 
Alan Modra
Australia Development Lab, IBM


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