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? _______________________________________________ Libunwind-devel mailing list Libunwind-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/libunwind-devel
