Re: [PATCH] Make _Unwind_GetIPInfo part of the ABI

["H.J. Lu" <hjl.tools@gmail.com>]

On Fri, Oct 21, 2016 at 11:11 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 10/21/2016 03:45 PM, Michael Matz wrote:
>>
>> Hi,
>>
>> On Fri, 21 Oct 2016, Florian Weimer wrote:
>>
>>> On 10/21/2016 02:58 PM, Michael Matz wrote:
>>>>
>>>> +This function returns the same value as \code{\_Unwind\_GetIP}.  In
>>>> +addition, the argument \code{ip\_before\_insn} must not be not null,
>>>> and
>>>> +\code{*ip\_before\_insn} is updated with a flag which indicates whether
>>>> +the returned pointer is at or after the first not yet fully executed
>>>> +instruction.
>>>
>>>
>>> I think this is rather misleading.  On x86_64, the location of the IP
>>> value is the same for calls and asynchronous signals: it always points
>>> to the next instruction to be executed.
>>
>>
>> No, that's simply wrong.  The saved instruction pointer points _at_ the
>> instruction causing the fault for faults, and _after_ the instruction for
>> traps.  Traps are things like single-stepping, breakpoints or INTO.  Most
>> other interrupts are faults or aborts (the latter being imprecise and
>> hence can't be restarted anyway).
>>
>> For calls the saved instruction pointer always points to after the call
>> and hence can be handled like a trap for unwinding purposes.
>
>
> Oh, then we are dealing with four different things: Calls, asynchronous
> signals (like the internal SIGCANCEL signal, which is how came to this
> topic), faults, and traps.
>
> Using your terminology, traps are like calls (IP adjustment needed).  An
> SIGCANCEL signal is like a fault because no IP adjustment is allowed. The
> GCC unwinders currently treat all the signals the same, which causes it to
> use the wrong handler region for traps.
>
>>> The difference that if we unwind through a call which has not yet
>>> returned, the caller is assumed to be still within the exception
>>> handling region in which the call instruction is located.  This is the
>>> consequence of the desired exception handling semantics of a
>>> non-returned function call.
>>
>>
>> Unwinding through one call or one trap is the same.  The interesting
>> instruction is the one ending right before the reported IP.
>
>
> Agreed.
>
>> Except for those situations where it doesn't, for which this function was
>> introduced to start with, in order to be able to differ between those
>> (basically the kernel needs to mark the signal frame as being the result
>> of a fault or a trap, and GetIPInfo uses this to set the flag).
>
>
> It's not really clear to me how the glibc unwinders tell traps from faults.
>
> Florian

We can set signal_frame to 0 for SIGCANCEL?

-- 
H.J.