Re: [PATCH] Make _Unwind_GetIPInfo part of the ABI

[Carlos O'Donell <carlos@redhat.com>]

On 10/21/2016 09:48 AM, Michael Matz wrote:
> Hi,
> 
> On Fri, 21 Oct 2016, Michael Matz 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.
> 
> Or rather, it isn't wrong, it's indeed pointing to the instruction to be 
> executed next after return from handler, as always.  But that's not the 
> important thing for unwinding: what you're interested in is the 
> instruction that _caused_ the interruption, and for that what I said 
> applies.

When you say "after the first not yet fully executed instruction" do you mean
"immediately after" or "some time after?"

On 32-bit hppa there is a delayed branch slot which means that after a call you are
two instructions past the call.

On 32-bit ARM you also have IP being two instructions beyond the call at any point
in time due to pipelining.

This would also mean the current code in gcc/libgcc/unwind-c.c needs to have a
target hook for it to be right?

-- 
Cheers,
Carlos.