Retpolines and CFI
Florian Weimer
fweimer@redhat.com
Thu Jan 25 08:40:00 GMT 2018
On 01/22/2018 01:21 PM, Florian Weimer wrote:
> 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.
I think it is possible to fix the second case by hiding the the return
address at the top of the stack, like this:
__x86_indirect_thunk_rax:
.LFB2:
.cfi_startproc
call .LIND5
.LIND4:
pause
lfence
jmp .LIND4
.LIND5:
.cfi_def_cfa_offset 16
mov %rax, (%rsp)
ret
.cfi_endproc
The unwinder should then use the other return address, from the caller
of the thunk routine.
Thanks,
Florian
More information about the Gcc
mailing list