linker bug 10515

[Nathan Sidwell]

I've been looking at linker bug 10515 
(http://sourceware.org/bugzilla/show_bug.cgi?id=10515) [the cvs-commit attached 
to it is a red-herring caused by a typoed bug number].

I attach a simpler testcase.  the bad.ld script is ordering elf segments such 
that the second segment should contain the file header and program headers.  As 
the file headers must be at offset zero, this forces the second segment to have 
a file offset of zero.  however, we process segment mappings in the order of the 
PHDRs list, so by the time we get to place the second segment, we've placed the 
first segment at file offset 0x10000.  This means we have to place the .text 
section at 0x20000, and hence the second elf segment spans over the first 
segment.  The end result of this is that the second segment has a rather odd vma 
and lma because it needs to begin 0x20000 bytes before the .text section.

We could improve this by processing the PHDRS list such that a segment that must 
include the file headers is processed before the other segment placements.  But 
as the PHDRs statement is there for exactly when the linker's automatic segment 
placement algorithm is insufficient, it seems rude for the linker to go altering 
  the placement specified in the PHDRS list.

I see two better solutions:

1) fix it in the documentation.  Add words to the 'PHDRS Command' section of the 
manual saying strange, but entirely logical, things happen if you attempt to add 
FILEHDRS and PHDRS to not-the-first segment.

2) make it an error to have FILEHDRS and/or PHDRS in not-the-first segment of 
the PHDRS statement.

thoughts?

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: asm.s
URL: <https://sourceware.org/pipermail/binutils/attachments/20091001/de1fff49/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bad.ld
URL: <https://sourceware.org/pipermail/binutils/attachments/20091001/de1fff49/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: good.ld
URL: <https://sourceware.org/pipermail/binutils/attachments/20091001/de1fff49/attachment-0002.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bad
Type: application/octet-stream
Size: 131428 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20091001/de1fff49/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: good
Type: application/octet-stream
Size: 131428 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20091001/de1fff49/attachment-0001.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bad.readelf
URL: <https://sourceware.org/pipermail/binutils/attachments/20091001/de1fff49/attachment-0003.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: good.readelf
URL: <https://sourceware.org/pipermail/binutils/attachments/20091001/de1fff49/attachment-0004.ksh>