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

[Doug Moore]

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?

Doug

Quoting Lassi Tuura <address@hidden>:

> The rationale from back in 2010 is in
> http://lists.gnu.org/archive/html/libunwind-devel/2010-04/msg00060.html
> plus surrounding thread, with earlier context on unwind failures in
> http://lists.gnu.org/archive/html/libunwind-devel/2010-03/msg00015.html
>
> There's also related earlier context in
> http://lists.gnu.org/archive/html/libunwind-devel/2008-01/msg00017.html
>
> As I mentioned in the first linked message, it seems improbable that
> unw_init_local() could ever be invoked from a signal frame itself. At that
> time, your use case of single stepping was mentioned as a counter-example.
> Would unw_init_remote() work for your use?
>
>
> On Fri, Mar 24, 2017 at 11:23 PM, Doug Moore <address@hidden> wrote:
>
> > Your change of Apr 24 2010 introduced the second argument to common_init,
> > and used it to pass 1 (use_prev_instr set) from unw_init_local and 0
> > (use_prev_instr clear) from unw_init_remote.  I don’t know how those
> > choices were made, but for my purposes, the choice for unw_init_local was
> > wrong, and I have to change that decision in the copy of libunwind that
> > we’ll use here.  I’d welcome an explanation of that decision.
> >
> > Doug
> >
> >
> > On Mar 24, 2017, at 11:37 AM, Lassi Tuura <address@hidden> wrote:
> >
> > What platform are you on? fetch_proc_info() should auto-detect signal
> > frame and set use_prev_instr accordingly using the (kernel-provided) frame
> > annotations detected in parse_cie(). I don't know if that works for
> > anything but linux (and possibly x86_64 only at that). Looks like there may
> > be some support for freebsd.
> >
> > On Thu, Mar 23, 2017 at 8:45 PM, Doug Moore <address@hidden> wrote:
> >
> > > When unw_init_local uses common_init to set use_prev_instr, and then
> > > fetch_proc_info decrements ip, based on use_prev_instr, unw_step fails for
> > > me.
> > >
> > > I’m putting a temp break point at the start of _dl_runtime_resolve, and
> > > when gdb gets there, I’m sending a signal to trigger a signal handler that
> > > invokes unw_step.  What happens, sadly, is that the instruction pointer is
> > > decremented, so the eh_frames search doesn’t find the right frame, so the
> > > step fails.
> > >
> > > If only I could clear that use_prev_instr field.  So far, I don’t have
> > > any better choices than to hack the libunwind source and maintain my own
> > > local branch.  Are there any better ideas?
> > >
> > > Doug
> > > _______________________________________________
> > > Libunwind-devel mailing list
> > > address@hidden
> > > https://lists.nongnu.org/mailman/listinfo/libunwind-devel
>
>
> !DSPAM:10223,58d7e45439341759858525!