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: ld --section-start prevents merging sections


On Tue, 17 Nov 2009, Alan Modra wrote:

On Fri, Nov 13, 2009 at 07:35:47PM -0800, H.J. Lu wrote:
On Fri, Nov 13, 2009 at 7:16 PM, Papalagi Pakeha
But then .. how come the sections are properly merged when not using
--section-start ?

How do you know that they are properly merged? IIRC the normal processing of similarly typed orphan sections would put them one after the other in order of appearance.

It may be related to:

http://sourceware.org/bugzilla/show_bug.cgi?id=10749

No, it is because the elf section type is wrongly set. --section-start results in a call to init_os lacking an input section, and thus

In other words, --section-start is processed before any oject files are read?

lacking knowledge of the correct output section type.  The first
orphan input section is mapped to the right output section because at
that point the section flags are also not set.  The second and
subsequent orphans fail the _bfd_elf_match_sections_by_type test at
line 1826 of elf32.em.

The result transforms the first .cryptext data to something deemed not compatible with later .cryptext data. The same transformation keeps being done until the linker runs out of .cryptext data.

Would starting with an implicit linker script do what he wants?

SECTIONS
     {
       .cryptext : { *(.cryptext) }
     }

The section would no longer be an orphan.

--
Michael   hennebry@web.cs.ndsu.NoDak.edu
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."


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