libunwind-devel
[Top][All Lists]
Advanced

[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





reply via email to

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