Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?

[Doug Moore]

> But I think we need to know the IP to detect signal frames? 


We need to know an IP, yes.  It’s not clear that we need the decremented-by-1 
IP, though.  Especially since we’re deciding whether to decrement it based on 
whether it’s in a signal frame or not.

I looked at the x86_64 implementations of unw_is_signal_frame for freebsd and 
linux.

For freebsd, unw_is_signal_frame uses the (unmodified) ip in the cursor 
argument to determine whether this is a signal frame.  So, for freebsd, we 
could call unw_is_signal_frame early, passing the cursor we had already, and 
use that to determine whether or not to use ip or ip-1 for searching 
dwarf/eh_frame structures.

For linux, unw_is_signal_frame does not look at the ip; it returns a value 
under the assumption that another function, either tdep_fetch_frame or 
tdep_cache_frame, has already set that value.  And tdep_fetch_frame does not 
look at the ip field of the cursor passed to it either.  Really, I’m not sure 
yet where the ip gets examined in the linux version of unw_is_signal_frame.

Doug


> On Mar 29, 2017, at 10:12 AM, Dave Watson <address@hidden> wrote:
> 
> On 03/27/17 05:36 PM, Doug Moore wrote:
>> It looks like the call to tdep_fetch_frame in fetch_proc_info would 
>> determine whether or not this was a signal frame, and thus whether or not we 
>> needed to use the previous instruction for the lookup.
>> 
>> Of course, we call tdep_fetch_frame only after we’ve already tried that 
>> lookup.  But perhaps some of the work done to identify signal frames could 
>> be moved up a bit, so that a better decision could be made about whether or 
>> not to use the previous instruction.
>> 
>> Does that make any sense?
> 
> But I think we need to know the IP to detect signal frames? 
> 
> My thought was that if IP-1 lookup failed, we could try IP lookup, and
> if it was a signal frame, use that instead (probably with verify=1)
> 
> !DSPAM:10223,58dbcee539347198113515!
> 
>