[Bug binutils/23595] New: "simple objcopy of executable" failure for msp430-elf with -mlarge

[jozef.l at mittosystems dot com]

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.