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

[Dave Watson]

On 03/26/17 11:43 AM, Doug Moore wrote:
> Thanks for those links.
> 
> You ask
> > Would unw_init_remote() work for your use?
> I tried, but the resulting binary crashed.  That may be because
> unw_init_remote does not include "c->validate = 0;" as does unw_init_local.
> Even if it did work, I don't think I could stand the performance penalty of
> using remote instead of local.
> 
> In any case, the implementations of local and remote clearly are not
> compliant with the online documentation for unw_init_local, which states:
> 
> > From a behavioral point of view, the call:
> > 
> >     ret = unw_init_local(&cursor, &ucontext);
> > 
> > is equivalent to:
> > 
> >     ret = unw_init_remote(&cursor, unw_local_addr_space,
> >                           &ucontext);
> 
> which is untrue because of the different values of use_prev_instr and
> validate assigned by the two.
> 
> The rationale from 2010 includes
> 
> > This seems almost impossible to run into with local unwinding - it's not
> > possible for unw_getcontext() to have signal trampoline as the caller.
> 
> but I am trying local unwinding with a context delivered by a signal
> handler, not by unw_getcontext, and so stepping, for me, fails as you
> described in 2010:
> 
> > 2) Failure to trace at function entry; .eh_frame information exists and
> > is correct. I suspect fetch_proc_info() should use "ip", not "--ip" to
> > locate the FDE. In all cases I examined there is no adjacent preceding
> > FDE, so lookup by ip-1 would come up empty.
> 
> At the moment, I'm defining a third flavor of unw_init to get me a cursor
> initialized to let me avoid this problem.  I'd rather be staying within the
> documented libunwind interface.  Can libunwind change to help me?

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?