[Bug ld/20830] New: .plt.got section is lacking unwind info

[keno at juliacomputing dot com]

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

            Bug ID: 20830
           Summary: .plt.got section is lacking unwind info
           Product: binutils
           Version: 2.27
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: keno at juliacomputing dot com
  Target Milestone: ---

Consider a simple executable, where one function needs both a GOT and PLT
entry, e.g.
```
.text
.globl _start
.type _start, @function
_start:
  .cfi_startproc
  .cfi_undefined %rip
  movq address@hidden(%rip), %rax
  callq address@hidden
  callq address@hidden
  movq address@hidden(%rip), %rax
  hlt
  .cfi_endproc
```
Now, ld is smart enough to combine the vanilla GOT entry and that required by
the PLT, placing a different kind of PLT stub in the `.plt.got` section:
```
gcc -c plt.S
ld -o plt plt.o plt-dyn.so ; plt-dyn is just some shared library that defines
these symbols
objdump -d plt

plt:     file format elf64-x86-64


Disassembly of section .plt:

0000000000400300 <address@hidden>:
  400300:       ff 35 02 0d 20 00       pushq  0x200d02(%rip)        # 601008
<_GLOBAL_OFFSET_TABLE_+0x8>
  400306:       ff 25 04 0d 20 00       jmpq   *0x200d04(%rip)        # 601010
<_GLOBAL_OFFSET_TABLE_+0x10>
  40030c:       0f 1f 40 00             nopl   0x0(%rax)

0000000000400310 <address@hidden>:
  400310:       ff 25 02 0d 20 00       jmpq   *0x200d02(%rip)        # 601018
<_GLOBAL_OFFSET_TABLE_+0x18>
  400316:       68 00 00 00 00          pushq  $0x0
  40031b:       e9 e0 ff ff ff          jmpq   400300 <address@hidden>

Disassembly of section .plt.got:

0000000000400320 <.plt.got>:
  400320:       ff 25 d2 0c 20 00       jmpq   *0x200cd2(%rip)        # 600ff8
<_DYNAMIC+0x148>
  400326:       66 90                   xchg   %ax,%ax

Disassembly of section .text:

0000000000400328 <_start>:
  400328:       48 8b 05 c9 0c 20 00    mov    0x200cc9(%rip),%rax        #
600ff8 <_DYNAMIC+0x148>
  40032f:       e8 ec ff ff ff          callq  400320 <address@hidden>
  400334:       e8 d7 ff ff ff          callq  400310 <address@hidden>
  400339:       48 8b 05 b0 0c 20 00    mov    0x200cb0(%rip),%rax        #
600ff0 <_DYNAMIC+0x140>
  400340:       f4                      hlt
```

which is very nice. Unfortunately, unlike the for .plt section, ld does not
create an FDE for the .plt.got section:

```
objdump --dwarf=frames

a.out:     file format elf64-x86-64

Contents of the .eh_frame section:

00000000 0000000000000014 00000000 CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16
  Augmentation data:     1b

  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_offset: r16 (rip) at cfa-8
  DW_CFA_undefined: r16 (rip)

00000018 0000000000000014 0000001c FDE cie=00000000
pc=0000000000400328..0000000000400341
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

00000030 0000000000000014 00000000 CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16
  Augmentation data:     1b

  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_offset: r16 (rip) at cfa-8
  DW_CFA_nop
  DW_CFA_nop

00000048 0000000000000024 0000001c FDE cie=00000030
pc=0000000000400300..0000000000400320
  DW_CFA_def_cfa_offset: 16
  DW_CFA_advance_loc: 6 to 0000000000400306
  DW_CFA_def_cfa_offset: 24
  DW_CFA_advance_loc: 10 to 0000000000400310
  DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 8; DW_OP_breg16 (rip): 0;
DW_OP_lit15; DW_OP_and; DW_OP_lit11; DW_OP_ge; DW_OP_lit3; DW_OP_shl;
DW_OP_plus)
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
```

Of course the .plt.got needs nothing fancy, just a simple DW_CFA_nop with the
same CIE as the .plt section would be sufficient. I should note that most
debuggers still get this right due to heuristics. However, there are unwinders
(e.g. in language runtimes), that purely rely on .eh_frame, so it would be nice
if the linker created the appropriate FDE.

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