Re: Issue with objcopy, removal of sections, and adjustment of unrelated sections

[Nick Clifton <nickc at redhat dot com>]

Hi Ronald,

> I am seeing some unexpected behavior from binutils objcopy, 

Which version of objcopy are you using ?


> This is the information on sections and headers I get when using readelf on the original ELF file:
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al

>   [38] .dummy_section_23 NOBITS          00500008 058008 07fff8 00  WA  0   0  1
>   [39] .fini_array       FINI_ARRAY      00580000 060000 000004 00  WA  0   0  4
>   [40] .dummy_section_24 NOBITS          00580004 060004 07fffc 00  WA  0   0  1
>   [41] .ARM.attributes   ARM_ATTRIBUTES  00600000 1959e8 000033 00      0   0  1

> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align

>   LOAD           0x060000 0x00580000 0x00580000 0x00004 0xfc01800 RW  0x8000     *
>   LOAD           0x068000 0x10000000 0x10000000 0x21458 0x21458 RW  0x8000 

> Take note of the header marked with an asterisk above.

Well for a start it looks very suspicious.  The MemSiz field looks to be huge.


> a) gives me the following I don't understand:
> 
> BFD: sjeng_blocking_sdim-textandrodata.other.elf: section .blob_text lma 0x10000000 adjusted to 0x10181800
> BFD: sjeng_blocking_sdim-textandrodata.other.elf: section .blob_gap_padding lma 0x10021458 adjusted to 0x101a2c58
> BFD: sjeng_blocking_sdim-textandrodata.other.elf: section .blob_rodata lma 0x100a0000 adjusted to 0x10221800

Hmm, these messages look bogus.  They certainly do not appear to match up with the final result.


>   LOAD           0x060000 0x00580000 0x00580000 0xfca8880 0xfca8880 RW  0x8000     *
>   LOAD           0xfd0a9d0 0x7001a9d0 0x7001a9d0 0x00000 0x65630 RWE 0x8000
> 
> Why are any sections being adjusted to new addresses?

(This information refers to *segments* or *program headers* if you prefer, and not *sections*.
It is important to be clear about this, because using the wrong term when talking about problems
like this can be very confusing).

Presumably the change is because objcopy has regenerated the program headers in what it thinks
is an efficient manner.  It also appears that something may have gone wrong...


> Also, you'll note that the header marked with an asterisk suddenly has a different size. Why was it changed?
> 
> Is this a bug?

Yes.  Precisely what is going wrong I cannot be sure.

> Note that I am using objcopy from a third-party binutils toolchain.

In which case it would be best to ask them for help.

If you want us to take a look at the problem you should first make sure that it can be reproduced
using the current FSF mainline binutils development sources.  Then file a bug report at the URL below,
including a testcase that reproduces the problem.

  https://sourceware.org/bugzilla/

Cheers
  Nick