[Bug binutils/32324] Stripping BOLT'ed binaries leads to unwanted behaviour

[avieira at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32324

--- Comment #1 from Andre Vieira <avieira at gcc dot gnu.org> ---
I did a bit more investigation and looking through the sections in the warning
I noticed something odd.

readelf --sections shows me:
Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
...
  [29] .eh_frame         PROGBITS         0000000000a00000  00600000
       0000000000003d08  0000000000000000   A       0     0     8
  [30] .eh_frame_hdr     PROGBITS         0000000000a03d08  00603d08
       0000000000000974  0000000000000000   A       0     0     1

and readelf -l shows me that .eh_frame and .eh_frame_hdr are meant to go in the
following segment (eh_frame_hdr also goes in the GNU_EH_FRAME):
Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
...
LOAD           0x0000000000200000 0x0000000000600000 0x0000000000600000
               0x000000000040467c 0x000000000040467c  R E    0x200000

It fails to allocate this section into this segment because the segment's
p_vaddr as calculated by: assign_file_positions_for_load_sections
through:
p->p_vaddr = (m->sections[0]->vma + m->p_vaddr_offset) * opb;

is only 0x430120 which leads to the warning because ELF_SECTION_IN_SEGMENT_1
fails the vma check:

((sec_hdr)->sh_addr - (segment)->p_vaddr + ELF_SECTION_SIZE(sec_hdr, segment))
<= (segment)->p_memsz

which leads to:
0xa00000 - 0x430120 +  0x3d08 <= 0x40467c
0x5d3be8 <= 0x40467c
false

This seems odd to me, given the section addres sh_addr, is now even beyond the
'new' end of the segment (p_vaddr + p_memsz), but it wasn't before. So we seem
to have moved the start of the segment but not the location of the sections?

-- 
You are receiving this mail because:
You are on the CC list for the bug.