ld maps sections without consider memory region?

Nick Clifton nickc@redhat.com
Thu Feb 22 05:53:00 GMT 2007


Hi Masaki,

> But I have a new question.
> I couldn't determine if this is my misunderstanding.
> 
> Using script-warn.ld with my test case, ld (applied your patch) shows an 
> warning like this.
> - mips64-elf-ld: a.out: warning: allocated section `.begin' \
> -  not in segmentThanks for your patch.
> But using script-no-warn.ld in same environment, there is no warning.
> I can't see why the warning is suppressed by defining HDR1 because it 
> looks HDR1  is never used by any sections.

Oh this was a good one to track down.  What is happening is this:

   If program headers are not specified in a linker script then the
   linker allows the BFD library to create a section-to-segment map
   and everything works as expected.

   If program headers are specified in a linker script then the linker
   walks over the list of headers checking to make sure that they are
   OK.  As a side effect of this it also remembers the last program
   header that it encounters and assigns this to sections that do not
   have a explicit segment associated with them.

   But - the code tries to be clever and combine these two things into
   one loop.  (See lang_record_phdrs() in ld/ldlang.c).  The practical
   result of this is that if there is only 1 program header then any
   sections which do not have a segment assigned to them before the first
   explicit mention of a program header will be left unassigned.  Whereas
   if there are 2 or more program headers then any section that misses
   out on a segment assignment when the first header is processed will
   receive an assignment when the second header is processed.

Anyway the attached patch should take care of this inconsistency.  Let 
me know what you think.

Cheers
   Nick




-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldlang.c.patch
Type: text/x-patch
Size: 1400 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20070222/856b59ee/attachment.bin>


More information about the Binutils mailing list