[Bug ld/16345] New: ld emits errors on .eh_frame from partial linking

[stilor at att dot net]

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

            Bug ID: 16345
           Summary: ld emits errors on .eh_frame from partial linking
           Product: binutils
           Version: 2.25 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: stilor at att dot net

Created attachment 7330
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7330&action=edit
Patch

If ld is used to partially link several object files that have different text
sections (e.g., .text and .init), the resulting object file (when used in
further linking) makes ld emit an error while reading .eh_frame sections.

Test case:

$ cat qq1.s 
.text
bar: .cfi_startproc; ret; .cfi_endproc
$ cat qq2.s 
.section .init,"ax",@progbits
.globl baz
baz: .cfi_startproc; ret; .cfi_endproc
$ /home/aneyman/work/install/bin/as -o qq1.o qq1.s
$ /home/aneyman/work/install/bin/as -o qq2.o qq2.s
$ /home/aneyman/work/install/bin/ld -r -o qq.o qq1.o qq2.o
$ /home/aneyman/work/install/bin/ld -o qq -e baz qq.o
/home/aneyman/work/install/bin/ld: error in qq.o(.eh_frame); no .eh_frame_hdr
table will be created.

The problem is that the code in bfd/elf-eh-frame.c assumes the relocations in
the .rela.eh_frame are ordered (see GET_RELOC/SKIP_RELOCS/ENSURE_NO_RELOCS
macros), but the assumption does not hold in the above scenario:

$ readelf -Wr qq.o 

Relocation section '.rela.eh_frame' at offset 0x370 contains 2 entries:
    Offset             Info             Type       Symbol's Value  Symbol's
Name + Addend
0000000000000050  0000000100000002 R_X86_64_PC32  0000000000000000 .init + 0
0000000000000020  0000000200000002 R_X86_64_PC32  0000000000000000 .text + 0

The attached patch makes the code in bfd/elf-eh-frame.c fall back to slower but
more resilient relocation search/check functions if it fails to interpret the
.eh_frame section with the ordering assumption. Patch does not add any
regressions to 'make check'.

I don't know if it would be right to sort the relocations on the output. If
needed, such sorting can be added separately.

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