On Thu, Jan 25, 2018 at 12:32 AM, Florian Weimer <fwei...@redhat.com> wrote: > 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.
Can you open a GCC bug to track it? Thanks. -- H.J.
