https://sourceware.org/bugzilla/show_bug.cgi?id=32308
Bug ID: 32308
Summary: OBJCOPY will gap-fill outside of loaded data
Product: binutils
Version: 2.42
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: eleventen at gmail dot com
Target Milestone: ---
Created attachment 15763
--> https://sourceware.org/bugzilla/attachment.cgi?id=15763&action=edit
Linked ELF that OBJDUMPs incorrectly
Greetings,
The attached linked binary was created using the ARM GCC build 12.2.Rel1. We
have verified the behavior below with both the 12.2.Rel1 version of objcopy and
the 13.3.Rel1 version.
GNU objcopy (Arm GNU Toolchain 13.3.Rel1 (Build arm-13.24)) 2.42.0.20240614
OBJCOPY will emit the binary correctly, unless the --gap-fill option is used or
if the empty .data section is also removed. We discovered this example because
we had linked our program in a way that included no initialized .data and found
that the objcopy to binary was emitting a 384MiB file.
1) objcopy -O binary fmt0-small fmt0-small.bin
The result is 10912 bytes.
2) objcopy -O binary --gap-fill=0xff fmt0-small fmt0-small.bin
The result 402661376 bytes.
3) objcopy -O binary -R .data --gap-fill=0xff fmt0-small fmt0-small.bin
The result is 10912 bytes.
The section header for .data would normally load with PROGBITS, but in this
case, the section is empty. We haven't found a way to conditionally emit .data
if it is non-empty which would work-around this particular case with a linker
script. We could certainly do so with a script. Yet, it does seem like this
is a glitch in the objdump (or perhaps the linker or BFD library).
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 08000000 010000 002510 00 AX 0 0
4
[ 2] .ARM.extab PROGBITS 08002510 012aa0 000000 00 W 0 0
1
[ 3] .rodata PROGBITS 08002510 012510 00058c 00 A 0 0
4
[ 4] .threads PROGBITS 08002a9c 012a9c 000004 00 A 0 0
4
[ 5] .stacks NOBITS 20000000 020000 002000 00 WA 0 0
1
[ 6] .data PROGBITS 20002000 012aa0 000000 00 WA 0 0
8
[ 7] .bss NOBITS 20002000 022000 00040c 00 WA 0 0
4
[ 8] .heap NOBITS 2000240c 02240c 02dbf4 00 WA 0 0
4
[ 9] .sram2a NOBITS 20030000 020000 008000 00 WA 0 0
4
[10] .sram2b NOBITS 20038000 018000 008000 00 WA 0 0
4
[11] .bkp NOBITS 40002850 022850 000050 00 WA 0 0
4
[12] .crc PROGBITS 08002aa0 012aa0 000000 00 A 0 0
4
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x010000 0x08000000 0x08000000 0x02aa0 0x02aa0 R E 0x10000
LOAD 0x002000 0x20002000 0x08002aa0 0x00000 0x0040c RW 0x10000
LOAD 0x00240c 0x2000240c 0x08002aa0 0x00000 0x2dbf4 RW 0x10000
LOAD 0x000000 0x20000000 0x20000000 0x00000 0x02000 RW 0x10000
LOAD 0x000000 0x20030000 0x20030000 0x00000 0x08000 RW 0x10000
LOAD 0x008000 0x20038000 0x20038000 0x00000 0x08000 RW 0x10000
LOAD 0x002850 0x40002850 0x40002850 0x00000 0x00050 RW 0x10000
Section to Segment mapping:
Segment Sections...
00 .text .rodata .threads
01 .bss
02 .heap
03 .stacks
04 .sram2a
05 .sram2b
Cheers
--
You are receiving this mail because:
You are on the CC list for the bug.
