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

[Doug Moore]

For linux, it’s not using the ip directly to determine is_signal_frame, but 
it’s using information from processing dwarf data, which it can only find if it 
has the right ip in the first place.

It seems like the init_cursor caller should be passing an argument to declare 
whether this is a signal handler frame or not.  I’d expect her to know that.  
It’s a lot more reliable that having libunwind try to figure it out.

Doug


> On Mar 29, 2017, at 3:33 PM, Doug Moore <address@hidden> wrote:
> 
>> 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!
>> 
>> 
>