libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Doug Moore
Subject: Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?
Date: Mon, 27 Mar 2017 17:36:14 -0500

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 <address@hidden> 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!
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]