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?

Doug

> On Mar 27, 2017, at 11:17 AM, Dave Watson <[email protected]> wrote:
> 
> On 03/27/17 08:46 AM, Dave Watson wrote:
>> It seems like we would need to parse the unwind info for the current
>> frame to correctly fill in use_prev_instr.  It looks like you might be
>> able to force this to happen by calling unw_get_proc_info(&c, &pip):
>> in Gparser.c:fetch_proc_info will fill in use_prev_instr for the
>> cursor. Does that work for you?
> 
>> fetch_proc_info checks c->use_prev_instr and, if it is set, decrements the ip
>> value as its first action.  Later, it might update c->use_prev_instr, but for
>> the first call, I'm stuck with the initial value, as set by unw_init_local.
> 
> Ack sorry, nevermind.  Yea I can't think of any way around this
> without a new init function, or a heursitic to try use_prev_instr=0 if
> we don't find unwind info (or something based on sigreturn maybe).
> 
> 
> !DSPAM:10223,58d93b2439342034620711!
> 
> 


_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel

Reply via email to