[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Doug Moore
Subject: Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?
Date: Fri, 24 Mar 2017 17:23:49 -0500

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.


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?

Libunwind-devel mailing list


reply via email to

[Prev in Thread] Current Thread [Next in Thread]