This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Retpolines and CFI


I tried this:

struct C {
  virtual ~C();
  virtual void f();
};

void
f (C *p)
{
  p->f();
  p->f();
}

with r256939 and -mindirect-branch=thunk -O2 on x86-64 GNU/Linux, and got this:

_Z1fP1C:
.LFB0:
        .cfi_startproc
        pushq   %rbx
        .cfi_def_cfa_offset 16
        .cfi_offset 3, -16
        movq    (%rdi), %rax
        movq    %rdi, %rbx
        jmp     .LIND1
.LIND0:
        pushq   16(%rax)
        jmp     __x86_indirect_thunk
.LIND1:
        call    .LIND0
        movq    (%rbx), %rax
        movq    %rbx, %rdi
        popq    %rbx
        .cfi_def_cfa_offset 8
        movq    16(%rax), %rax
        jmp     __x86_indirect_thunk_rax
        .cfi_endproc

This doesn't look quite right. x86-64 is supposed to have asynchronous unwind tables by default, but there is nothing that reflects the change in the (relative) frame address after .LIND0. I think that region really has to be moved outside of the .cfi_startproc/.cfi_endproc bracket.

There is a different issue with the think itself.

__x86_indirect_thunk_rax:
.LFB2:
        .cfi_startproc
        call    .LIND5
.LIND4:
        pause
        lfence
        jmp     .LIND4
.LIND5:
        mov     %rax, (%rsp)
        ret
        .cfi_endproc

If a signal is delivered after the mov has executed, the unwinder will eventually unwind through the signal frame and hit __x86_indirect_thunk_rax. It does not treat it as a signal frame, so the return address of the stack is decremented by one, in an attempt to obtain a program counter value which is within the call instruction. However, in this scenario, the return address is actually the start of the function, and subtracting one moves the program counter out of the unwind region for that function.

Both issues are visible in GDB if you set breakpoints in the proper places because the frame information used for debugging is incorrect as well.

This probably does not concern the kernel that much, but it is definitely a problem for userspace.

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]