fix strip & objcopy bug with foreign linker

[Nathan Sidwell]

This patch fixes a problem encountered with stripping vxworks RTPs generated by
the Diab linker.

Diab places padding after the program headers before the first section in a
loadable segment.  We were failing to maintain this padding, resulting in the
following change to an executable upon stripping:

before:
    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
    PHDR           0x000034 0x10000034 0x00000000 0x00080 0x00080 R   0x4
    LOAD           0x000000 0x10000000 0x00000000 0x09404 0x09404 R E 0x1
    LOAD           0x009404 0x1000a404 0x00000000 0x00174 0x004e8 RW  0x1
    DYNAMIC        0x009404 0x1000a404 0x00000000 0x00088 0x00088 R   0x4

after:
    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
    PHDR           0x000034 0x10000040 0x10000040 0x00080 0x00080 R   0x4
    LOAD           0x000000 0x1000000c 0x1000000c 0x093f8 0x093f8 R E 0x1
    LOAD           0x0093f8 0x1000a404 0x1000a404 0x00174 0x004e8 RW  0x1
    DYNAMIC        0x0093f8 0x1000a404 0x1000a404 0x00088 0x00088 R   0x4

You can see that the first loadable segment is still at file offset zero, but is
now loaded at address 0x1000000c.  So the file header is loaded 12 bytes further
on than expected.

The rtp loader is now setting an absolute symbol at the file-header's load
address, and expects strip to not break that.

This patch determines the space used for file and program headers in the input
file, and then uses this to create the same space in the output file.  If that's
insufficient we'll get the same kind of error as we currently get -- no changes
are necessary.  With this patch, the stripped segments become:

    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
    PHDR           0x000034 0x10000034 0x10000034 0x00080 0x00080 R   0x4
    LOAD           0x000000 0x10000000 0x10000000 0x09404 0x09404 R E 0x1
    LOAD           0x009404 0x1000a404 0x1000a404 0x00174 0x004e8 RW  0x1
    DYNAMIC        0x009404 0x1000a404 0x1000a404 0x00088 0x00088 R   0x4

which as you can see is the same as the original file.

tested with powerpc-elf and i686-pc-linux-gnu. ok?

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


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: all.diff
URL: <https://sourceware.org/pipermail/binutils/attachments/20081111/0e2aedbe/attachment.ksh>