https://sourceware.org/bugzilla/show_bug.cgi?id=23595
Bug ID: 23595
Summary: "simple objcopy of executable" failure for msp430-elf
with -mlarge
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: jozef.l at mittosystems dot com
Target Milestone: ---
Created attachment 11217
--> https://sourceware.org/bugzilla/attachment.cgi?id=11217&action=edit
testprog
The attached "testprog" was built by the testsuite. "copyprog" was generated by
"objcopy testprog copyprog".
These commands can be used to replicate how the testsuite builds the program:
msp430-elf-gcc -mlarge -c -msim -o testglue.o /usr/share/dejagnu/testglue.c
msp430-elf-gcc -mlarge -c -msim -o testprog.o \
binutils-gdb/binutils/testsuite/binutils-all/testprog.c
msp430-elf-gcc -mlarge testprog.o testglue.o -Wl,-wrap,exit -Wl,-wrap,_exit \
-Wl,-wrap,main -Wl,-wrap,abort -msim -Lbinutils-gdb/build-msp430/ld -g -lm -o
testprog
msp430-elf-objcopy testprog copyprog
Trimmed readelf -lS output is below
testprog
--
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf
Al
[ 2] .rodata PROGBITS 00002000 000134 000090 00 A 0 0
2
[ 7] .bss NOBITS 0000063e 000136 00002c 00 WA 0 0
2
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00000508 0x00000508 0x00134 0x00162 RW 0x4
LOAD 0x000134 0x00002000 0x00002000 0x00090 0x00090 R 0x4
copyprog
--
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf
Al
[ 2] .rodata PROGBITS 00002000 000138 000090 00 A 0 0
2
[ 7] .bss NOBITS 0000063e 000136 00002c 00 WA 0 0
2
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00000508 0x00000508 0x00136 0x00162 RW 0x4
LOAD 0x000138 0x00002000 0x00002000 0x00090 0x00090 R 0x4
testprog and copyprog
---
Section to Segment mapping:
Segment Sections...
00 .bss
01 .rodata
Incorrect values in copyprog:
- File offset for .rodata (0x134 -> 0x138)
- File size of the first segment (0x134 -> 0x136)
- File offset of second segment (0x134 -> 0x138)
Since the first segment contains the program headers and the SHT_NOBITS section
".bss" only, it contains no loadable sections. This means the segment is marked
as "no_contents", (see elf.c:5450) and any increase of the file offset (to make
the segment obey the gABI requirement for VMA page alignemnt), is then taken
away from the file offset counter (off), which is used to place subsequent
sections/segments.
In this case, the offset of .bss is adjusted from 0x134 to 0x136 in the linker,
then the offset counter is decremented back to 0x134 (because the segment has
no_contents), so the next section (in the next segment), .rodata, is placed at
0x134.
When objcopy comes to assign_file_positions_for_load_sections, it thinks the
size of the program headers (m->header_size) is 0x136, so .bss will be
considered for placement at offset 0x136, not 0x134 as we get in the linker.
It can be placed at 0x136 without any off_adjust value required, so .rodata is
considered for placement at 0x136.
The header size is originally set in elf.c:7351 (copy_elf_program_header).
map->header_size = lowest_section->vma - segment->p_vaddr
When segment->p_vaddr is finalized (in the linker, bfd/elf.c:5506), it uses the
file offset counter, which includes the added alignment (off_adjust)
required for .bss.
In this case, the above calculation is essentially
map->header_size = lowest_section->vma - (lowest_section->vma -
bss->sh_offset)
map->header_size = bss->sh_offset
So this calculation is innacurate, as it assumes the lowest_section VMA is
immediately after the program headers, when in fact the lowest_section may have
been aligned, and so does not start immediately after the headers.
If the first segment containing the program headers does have contents, then
this bug
doesn't occur. Even if the header_size is technically innacurate, it doesn't
matter because there is no off_adjust value that the linker used to change the
offset of the second segment, unbeknownst to objcopy, so it is fine to use this
header_size value as the starting point for the file offset of sections.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
