* Issue with objcopy, removal of sections, and adjustment of unrelated sections
@ 2016-08-01 14:26 Ronald De Keulenaer
2016-08-02 13:44 ` Nick Clifton
0 siblings, 1 reply; 2+ messages in thread
From: Ronald De Keulenaer @ 2016-08-01 14:26 UTC (permalink / raw)
To: binutils
Hello,
I am seeing some unexpected behavior from binutils objcopy, which
occurs when I attempt to remove sections from an ELF file.
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
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .dummy_section_01 PROGBITS 70000000 1959e8 000000 00
W 0 0 1
[ 2] .text_benchmark PROGBITS 70000000 110000 01a9d0 00
AX 0 0 8
[ 3] .gap_padding_benc PROGBITS 7001a9e0 12a9e0 065620 00
WA 0 0 1
[ 4] .dummy_section_02 NOBITS 7001a9d0 12a9d0 065630 00
WA 0 0 1
[ 5] .rodata_benchmark PROGBITS 70080000 190000 0059e8 00
A 0 0 4
[ 6] .dummy_section_03 PROGBITS 00100000 1959e8 000000 00
W 0 0 1
[ 7] .text PROGBITS 00100000 008000 016f20 00
AX 0 0 64
[ 8] .blob_text PROGBITS 10000000 068000 021458 00
WA 0 0 1
[ 9] .blob_gap_padding PROGBITS 10021458 089458 07eba8 00
WA 0 0 1
[10] .blob_rodata PROGBITS 100a0000 108000 007080 00
WA 0 0 1
[11] .dummy_section_04 NOBITS 00116f20 01ef20 0690e0 00
WA 0 0 1
[12] .init PROGBITS 00180000 020000 000018 00
AX 0 0 4
[13] .dummy_section_05 NOBITS 00180018 020018 07ffe8 00
WA 0 0 1
[14] .fini PROGBITS 00200000 028000 000018 00
AX 0 0 4
[15] .dummy_section_06 NOBITS 00200018 028018 07ffe8 00
WA 0 0 1
[16] .rodata PROGBITS 00280000 030000 00732c 00
A 0 0 8
[17] .dummy_section_07 NOBITS 0028732c 03732c 078cd4 00
WA 0 0 1
[18] .dummy_section_08 PROGBITS 00300000 1959e8 000000 00
W 0 0 1
[19] .dummy_section_09 PROGBITS 00300000 1959e8 000000 00
W 0 0 1
[20] .dummy_section_10 PROGBITS 00300000 1959e8 000000 00
W 0 0 1
[21] .data PROGBITS 00300000 038000 001080 00
WA 0 0 8
[22] .dummy_section_11 NOBITS 00301080 039080 07ef80 00
WA 0 0 1
[23] .dummy_section_12 PROGBITS 00380000 1959e8 000000 00
W 0 0 1
[24] .dummy_section_13 PROGBITS 00380000 1959e8 000000 00
W 0 0 1
[25] .dummy_section_14 PROGBITS 00380000 1959e8 000000 00
W 0 0 1
[26] .dummy_section_15 PROGBITS 00380000 1959e8 000000 00
W 0 0 1
[27] .dummy_section_16 PROGBITS 00380000 1959e8 000000 00
W 0 0 1
[28] .eh_frame PROGBITS 00380000 040000 000004 00
A 0 0 4
[29] .dummy_section_17 NOBITS 00380004 040004 07fffc 00
WA 0 0 1
[30] .dummy_section_18 PROGBITS 00400000 1959e8 000000 00
W 0 0 1
[31] .dummy_section_19 PROGBITS 00400000 1959e8 000000 00
W 0 0 1
[32] .mmu_tbl PROGBITS 00400000 048000 004000 00
A 0 0 1
[33] .dummy_section_20 NOBITS 00404000 04c000 07c000 00
WA 0 0 1
[34] .ARM.exidx ARM_EXIDX 00480000 050000 000008 00
AL 7 0 4
[35] .dummy_section_21 NOBITS 00480008 050008 07fff8 00
WA 0 0 1
[36] .dummy_section_22 PROGBITS 00500000 1959e8 000000 00
W 0 0 1
[37] .init_array INIT_ARRAY 00500000 058000 000008 00
WA 0 0 4
[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
[42] .dummy_section_25 PROGBITS 00600000 195a1b 000000 00
W 0 0 1
[43] .dummy_section_26 PROGBITS 00600000 195a1b 000000 00
W 0 0 1
[44] .dummy_section_27 PROGBITS 00600000 195a1b 000000 00
W 0 0 1
[45] .dummy_section_28 PROGBITS 00600000 195a1b 000000 00
W 0 0 1
[46] .dummy_section_29 PROGBITS 00600000 195a1b 000000 00
W 0 0 1
[47] .bss NOBITS 00600000 060004 27a66c 00
WA 0 0 4
[48] .dummy_section_30 NOBITS 0087a66c 060004 005994 00
WA 0 0 1
[49] .heap NOBITS 00880000 060004 e900000 00
WA 0 0 1
[50] .dummy_section_31 PROGBITS 0f180000 195a1b 000000 00
W 0 0 1
[51] .stack NOBITS 0f180000 060004 1001800 00
WA 0 0 1
[52] .debug_info PROGBITS 00000000 195a1b 017986 00
0 0 1
[53] .debug_abbrev PROGBITS 00000000 1ad3a1 005164 00
0 0 1
[54] .debug_loc PROGBITS 00000000 1b2505 011154 00
0 0 1
[55] .debug_aranges PROGBITS 00000000 1c3660 0007b0 00
0 0 8
[56] .debug_macro PROGBITS 00000000 1c3e10 007ea9 00
0 0 1
[57] .debug_line PROGBITS 00000000 1cbcb9 00ccc3 00
0 0 1
[58] .debug_str PROGBITS 00000000 1d897c 016c11 01
MS 0 0 1
[59] .comment PROGBITS 00000000 1ef58d 000030 01
MS 0 0 1
[60] .debug_frame PROGBITS 00000000 1ef5c0 004440 00
0 0 4
[61] .debug_ranges PROGBITS 00000000 1f3a00 000848 00
0 0 1
[62] .shstrtab STRTAB 00000000 1f4248 0003a0 00
0 0 1
[63] .symtab SYMTAB 00000000 1f5010 0071b0 10
64 994 4
[64] .strtab STRTAB 00000000 1fc1c0 00394e 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
EXIDX 0x050000 0x00480000 0x00480000 0x00008 0x00008 R 0x4
LOAD 0x008000 0x00100000 0x00100000 0x16f20 0x80000 RWE 0x8000
LOAD 0x020000 0x00180000 0x00180000 0x00018 0x80000 RWE 0x8000
LOAD 0x028000 0x00200000 0x00200000 0x00018 0x80000 RWE 0x8000
LOAD 0x030000 0x00280000 0x00280000 0x0732c 0x80000 RW 0x8000
LOAD 0x038000 0x00300000 0x00300000 0x01080 0x80000 RW 0x8000
LOAD 0x040000 0x00380000 0x00380000 0x00004 0x80000 RW 0x8000
LOAD 0x048000 0x00400000 0x00400000 0x04000 0x80000 RW 0x8000
LOAD 0x050000 0x00480000 0x00480000 0x00008 0x80000 RW 0x8000
LOAD 0x058000 0x00500000 0x00500000 0x00008 0x80000 RW 0x8000
LOAD 0x060000 0x00580000 0x00580000 0x00004 0xfc01800 RW
0x8000 *
LOAD 0x068000 0x10000000 0x10000000 0x21458 0x21458 RW 0x8000
LOAD 0x089458 0x10021458 0x10021458 0x7eba8 0x7eba8 RW 0x8000
LOAD 0x108000 0x100a0000 0x100a0000 0x07080 0x07080 RW 0x8000
LOAD 0x110000 0x70000000 0x70000000 0x1a9d0 0x80000 RWE 0x8000
LOAD 0x12a9e0 0x7001a9e0 0x7001a9e0 0x65620 0x65620 RW 0x8000
LOAD 0x190000 0x70080000 0x70080000 0x059e8 0x059e8 R 0x8000
Take note of the header marked with an asterisk above.
I then execute
arm-xilinx-eabi-objcopy --remove-section .text_benchmark
--remove-section .rodata_benchmark --remove-section
.gap_padding_benchmark original.elf rewritten.elf
Which
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
b) makes it so I end up with the following information on the rewritten file:
Section Headers:
[Nr] Name Type Addr Off Size ES
Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .dummy_section_01 PROGBITS 70000000 fd08880 000000 00
W 0 0 1
[ 2] .dummy_section_02 NOBITS 7001a9d0 fd0a9d0 065630 00
WA 0 0 1
[ 3] .dummy_section_03 PROGBITS 00100000 fd08880 000000 00
W 0 0 1
[ 4] .text PROGBITS 00100000 008000 016f20 00
AX 0 0 64
[ 5] .blob_text PROGBITS 10000000 fc61800 021458 00
WA 0 0 1
[ 6] .blob_gap_padding PROGBITS 10021458 fc82c58 07eba8 00
WA 0 0 1
[ 7] .blob_rodata PROGBITS 100a0000 fd01800 007080 00
WA 0 0 1
[ 8] .dummy_section_04 NOBITS 00116f20 01ef20 0690e0 00
WA 0 0 1
[ 9] .init PROGBITS 00180000 020000 000018 00
AX 0 0 4
[10] .dummy_section_05 NOBITS 00180018 020018 07ffe8 00
WA 0 0 1
[11] .fini PROGBITS 00200000 028000 000018 00
AX 0 0 4
[12] .dummy_section_06 NOBITS 00200018 028018 07ffe8 00
WA 0 0 1
[13] .rodata PROGBITS 00280000 030000 00732c 00
A 0 0 8
[14] .dummy_section_07 NOBITS 0028732c 03732c 078cd4 00
WA 0 0 1
[15] .dummy_section_08 PROGBITS 00300000 fd08880 000000 00
W 0 0 1
[16] .dummy_section_09 PROGBITS 00300000 fd08880 000000 00
W 0 0 1
[17] .dummy_section_10 PROGBITS 00300000 fd08880 000000 00
W 0 0 1
[18] .data PROGBITS 00300000 038000 001080 00
WA 0 0 8
[19] .dummy_section_11 NOBITS 00301080 039080 07ef80 00
WA 0 0 1
[20] .dummy_section_12 PROGBITS 00380000 fd08880 000000 00
W 0 0 1
[21] .dummy_section_13 PROGBITS 00380000 fd08880 000000 00
W 0 0 1
[22] .dummy_section_14 PROGBITS 00380000 fd08880 000000 00
W 0 0 1
[23] .dummy_section_15 PROGBITS 00380000 fd08880 000000 00
W 0 0 1
[24] .dummy_section_16 PROGBITS 00380000 fd08880 000000 00
W 0 0 1
[25] .eh_frame PROGBITS 00380000 040000 000004 00
A 0 0 4
[26] .dummy_section_17 NOBITS 00380004 040004 07fffc 00
WA 0 0 1
[27] .dummy_section_18 PROGBITS 00400000 fd08880 000000 00
W 0 0 1
[28] .dummy_section_19 PROGBITS 00400000 fd08880 000000 00
W 0 0 1
[29] .mmu_tbl PROGBITS 00400000 048000 004000 00
A 0 0 1
[30] .dummy_section_20 NOBITS 00404000 04c000 07c000 00
WA 0 0 1
[31] .ARM.exidx ARM_EXIDX 00480000 050000 000008 00
AL 4 0 4
[32] .dummy_section_21 NOBITS 00480008 050008 07fff8 00
WA 0 0 1
[33] .dummy_section_22 PROGBITS 00500000 fd08880 000000 00
W 0 0 1
[34] .init_array INIT_ARRAY 00500000 058000 000008 00
WA 0 0 4
[35] .dummy_section_23 NOBITS 00500008 058008 07fff8 00
WA 0 0 1
[36] .fini_array FINI_ARRAY 00580000 060000 000004 00
WA 0 0 4
[37] .dummy_section_24 NOBITS 00580004 060004 07fffc 00
WA 0 0 1
[38] .ARM.attributes ARM_ATTRIBUTES 00600000 fd08880 000033 00
0 0 1
[39] .dummy_section_25 PROGBITS 00600000 fd088b3 000000 00
W 0 0 1
[40] .dummy_section_26 PROGBITS 00600000 fd088b3 000000 00
W 0 0 1
[41] .dummy_section_27 PROGBITS 00600000 fd088b3 000000 00
W 0 0 1
[42] .dummy_section_28 PROGBITS 00600000 fd088b3 000000 00
W 0 0 1
[43] .dummy_section_29 PROGBITS 00600000 fd088b3 000000 00
W 0 0 1
[44] .bss NOBITS 00600000 060004 27a66c 00
WA 0 0 4
[45] .dummy_section_30 NOBITS 0087a66c 060004 005994 00
WA 0 0 1
[46] .heap NOBITS 00880000 060004 e900000 00
WA 0 0 1
[47] .dummy_section_31 PROGBITS 0f180000 fd088b3 000000 00
W 0 0 1
[48] .stack NOBITS 0f180000 060004 1001800 00
WA 0 0 1
[49] .debug_info PROGBITS 00000000 fd088b3 017986 00
0 0 1
[50] .debug_abbrev PROGBITS 00000000 fd20239 005164 00
0 0 1
[51] .debug_loc PROGBITS 00000000 fd2539d 011154 00
0 0 1
[52] .debug_aranges PROGBITS 00000000 fd364f8 0007b0 00
0 0 8
[53] .debug_macro PROGBITS 00000000 fd36ca8 007ea9 00
0 0 1
[54] .debug_line PROGBITS 00000000 fd3eb51 00ccc3 00
0 0 1
[55] .debug_str PROGBITS 00000000 fd4b814 016c11 01
MS 0 0 1
[56] .comment PROGBITS 00000000 fd62425 000030 01
MS 0 0 1
[57] .debug_frame PROGBITS 00000000 fd62458 004440 00
0 0 4
[58] .debug_ranges PROGBITS 00000000 fd66898 000848 00
0 0 1
[59] .shstrtab STRTAB 00000000 fd670e0 000367 00
0 0 1
[60] .symtab SYMTAB 00000000 fd67df8 0059d0 10
61 774 4
[61] .strtab STRTAB 00000000 fd6d7c8 002eba 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
EXIDX 0x050000 0x00480000 0x00480000 0x00008 0x00008 R 0x4
LOAD 0x008000 0x00100000 0x00100000 0x16f20 0x80000 RWE 0x8000
LOAD 0x020000 0x00180000 0x00180000 0x00018 0x80000 RWE 0x8000
LOAD 0x028000 0x00200000 0x00200000 0x00018 0x80000 RWE 0x8000
LOAD 0x030000 0x00280000 0x00280000 0x0732c 0x80000 RW 0x8000
LOAD 0x038000 0x00300000 0x00300000 0x01080 0x80000 RW 0x8000
LOAD 0x040000 0x00380000 0x00380000 0x00004 0x80000 RW 0x8000
LOAD 0x048000 0x00400000 0x00400000 0x04000 0x80000 RW 0x8000
LOAD 0x050000 0x00480000 0x00480000 0x00008 0x80000 RW 0x8000
LOAD 0x058000 0x00500000 0x00500000 0x00008 0x80000 RW 0x8000
LOAD 0x060000 0x00580000 0x00580000 0xfca8880 0xfca8880
RW 0x8000 *
LOAD 0xfd0a9d0 0x7001a9d0 0x7001a9d0 0x00000 0x65630 RWE 0x8000
LOAD 0xfd08880 0x00000000 0x00000000 0x00000 0x00000 R 0x8000
Why are any sections being adjusted to new addresses?
Also, you'll note that the header marked with an asterisk suddenly has
a different size. Why was it changed?
Is this a bug? Note that I am using objcopy from a third-party
binutils toolchain.
Thanks in advance for any and all help!
Best regards,
Ronald De Keulenaer
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Issue with objcopy, removal of sections, and adjustment of unrelated sections
2016-08-01 14:26 Issue with objcopy, removal of sections, and adjustment of unrelated sections Ronald De Keulenaer
@ 2016-08-02 13:44 ` Nick Clifton
0 siblings, 0 replies; 2+ messages in thread
From: Nick Clifton @ 2016-08-02 13:44 UTC (permalink / raw)
To: Ronald De Keulenaer, binutils
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-08-02 13:44 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-01 14:26 Issue with objcopy, removal of sections, and adjustment of unrelated sections Ronald De Keulenaer
2016-08-02 13:44 ` Nick Clifton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).