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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.nongnu.org/mailman/listinfo/libunwind-devel > <https://lists.nongnu.org/mailman/listinfo/libunwind-devel> > > !DSPAM:10223,58d54b7039342953010367!
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
