Platform:
Linux phi.cs.rice.edu 3.10.0-123.el7.x86_64 #1 SMP Mon Jun 30 12:09:22
UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
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.
Doug
Quoting Lassi Tuura <[email protected]>:
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]> 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]
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
