This is the mail archive of the
mailing list for the binutils project.
Re: Issue with objcopy, removal of sections, and adjustment of unrelated sections
- From: Nick Clifton <nickc at redhat dot com>
- To: Ronald De Keulenaer <ronald dot dekeulenaer at elis dot ugent dot be>, binutils at sourceware dot org
- Date: Tue, 2 Aug 2016 14:43:54 +0100
- Subject: Re: Issue with objcopy, removal of sections, and adjustment of unrelated sections
- Authentication-results: sourceware.org; auth=none
- References: <20160801162547.Horde.Q8eLEy2wqn5Xn1vriWQBNPA@mail.elis.ugent.be>
> 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
>  .dummy_section_23 NOBITS 00500008 058008 07fff8 00 WA 0 0 1
>  .fini_array FINI_ARRAY 00580000 060000 000004 00 WA 0 0 4
>  .dummy_section_24 NOBITS 00580004 060004 07fffc 00 WA 0 0 1
>  .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.