leading padding in ELF segment

[Nathan Sidwell <nathan at codesourcery dot com>]

Wind River's Diab compiler produces somewhat funky ELF files.  They contain 
loadable segments that neither start at a section boundary, nor contain file or 
program headers.  here's an example

Section Headers:
  [Nr] Name    Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]         NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text   PROGBITS        00010000 000080 0caa28 00  AX  0   0 32
  [ 2] .data   PROGBITS        000dc000 0cc080 00c8f0 00  WA  0   0 16384
  [ 3] .bss    NOBITS          000e88f0 0d8970 0160c0 00  WA  0   0 16

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000080 0x00010000 0x00010000 0xcaa28 0xcaa28 R E 0x1
  LOAD           0x0caaa8 0x000daa28 0x000daa28 0x0dec8 0x23f88 RW  0x1

The first segment contains exactly the .text section.  The 2nd segment starts 
immediately after that, so the .data section is some 0x15d8 bytes into it.  The 
.text section's file offset is aligned to the .text section's alignment.  The 
.data section's file offset is not so aligned.  Although I can't find words in 
the ELF spec to suppose that a section's file offset should be aligned, Diab 
does seem to be behaving inconsistently here.

Question:  Is this a well formed ELF file?  AFAICT it is.

The problem is that objcopy and strip mangle this file, because BFD is not 
prepared to deal with such a segment.  It expects either the start of a segment 
to be coincident with a section, or the segment to contain file and/or program 
headers.  We end up with the 2nd output section's virtual address being broken, 
and we also set the two segments' alignments from their most strictly aligned 
contained section.

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk