[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Libunwind-devel] question about is_signal_frame and usage
From: |
Corey Ashford |
Subject: |
[Libunwind-devel] question about is_signal_frame and usage |
Date: |
Tue, 27 Feb 2007 11:15:19 -0800 |
User-agent: |
Thunderbird 1.5.0.9 (Windows/20061207) |
I've been debugging a test case (a variant of test-async-sig) that
occasionally gets an error during unwinding through a signal handler.
The error occurs when the signal interrupts the first instruction of
function.
I've narrowed down the problem to this sequence in dwarf/Gparser.c:
static int
fetch_proc_info (struct dwarf_cursor *c, unw_word_t ip, int need_unwind_info)
{
int ret, dynamic = 1;
/* In the current (lowest) frame we must not touch `ip' as the current
address is where we stand. On the other hand any upper frames will stand
on the next instruction behind our call which may have a different stack
DWARF information (for `stdcall' called functions) or the next instruction
even may belong already to a different continuing function.
Also signal frames got invoked from the instruction we want to analyze. */
if (c->decrease_ip)
--ip;
...
The problem here is that the frame we are unwinding is no longer a
"signal frame" (I think). In my current PowerPC port, a signal frame is
recognized by looking for the signal return trampoline code at the
current IP address.
Because this function IP is not recognized as a signal frame,
c->decrease_ip is set to true, which moves the IP out of the function to
whatever cruft precedes the function. Consequently, the proc info is
not found and returns an error.
Have I misunderstood how is_signal_frame is supposed to be implemented?
Currently, I use is_signal_frame in ppc64/Gstep.c to determine if I
should use the ucontext record on the stack to restore the registers.
If I were to somehow change is_signal_frame to recognize the interrupted
frame as a "signal frame" too, this would mess up Gstep's logic.
Any suggestions and advice would be appreciated.
Thanks for your consideration,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
address@hidden
- [Libunwind-devel] question about is_signal_frame and usage,
Corey Ashford <=