GDB backtrace and signal trampolines

GDB backtrace and signal trampolines

[Hollis Blanchard]

GDB 6.3 contains this code in ppc-linux-tdep.c:

static const struct frame_unwind *
ppc_linux_sigtramp_sniffer (struct frame_info *next_frame)
{
   struct gdbarch_tdep *tdep = gdbarch_tdep (get_frame_arch 
(next_frame));

   if (frame_pc_unwind (next_frame)
       > frame_unwind_register_unsigned (next_frame, SP_REGNUM))
     /* Assume anything that is vaguely on the stack is a signal
        trampoline.  */
     return &ppc_linux_sigtramp_unwind;
   else
     return NULL;
}

Essentially it says that any time the program counter is above the 
stack pointer, we must be in a signal trampoline, and so GDB proceeds 
to grope about for a struct rt_sigframe on the stack.

This is not a good assumption. I'm using a GDB stub to debug Xen, and 
as it so happens, the Xen stack is below the Xen text. That means that 
the above test always triggers, but of course there is no rt_sigframe 
on the stack, and my backtrace runs away.

Would it make sense to limit the test to within a few hundred bytes of 
the stack pointer? Or some better way to detect that the PC is in a 
signal trampoline?

(Also, how can I test backtraces within a signal trampoline? I've 
single-stepped my way into and out of a signal hander, and never saw 
the PC inside the stack.)

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: GDB backtrace and signal trampolines

[Anton Blanchard]

Hi,

> Would it make sense to limit the test to within a few hundred bytes of 
> the stack pointer? Or some better way to detect that the PC is in a 
> signal trampoline?

With recent kernels we should be able to use the dwarf2 unwind
information in the vdso I think.

Anton

Re: GDB backtrace and signal trampolines

[Hollis Blanchard]

On Aug 12, 2005, at 12:06 AM, Anton Blanchard wrote:
>
>> Would it make sense to limit the test to within a few hundred bytes of
>> the stack pointer? Or some better way to detect that the PC is in a
>> signal trampoline?
>
> With recent kernels we should be able to use the dwarf2 unwind
> information in the vdso I think.

I guess compatibility with older kernels will still need to be 
maintained, though.

I see this note in arch/ppc64/mm/fault.c:
         /*
          * N.B. The POWER/Open ABI allows programs to access up to
          * 288 bytes below the stack pointer.
          * The kernel signal delivery code writes up to about 1.5kB
          * below the stack pointer (r1) before decrementing it.
          * The exec code can write slightly over 640kB to the stack
          * before setting the user r1.  Thus we allow the stack to
          * expand to 1MB without further checks.
          */

So would 2KB be a reasonable limit to the signal frame check, as I 
described before?

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: GDB backtrace and signal trampolines

[Hollis Blanchard]

On Aug 11, 2005, at 10:54 AM, Hollis Blanchard wrote:

> GDB 6.3 contains this code in ppc-linux-tdep.c:
>
> static const struct frame_unwind *
> ppc_linux_sigtramp_sniffer (struct frame_info *next_frame)
> {
>   struct gdbarch_tdep *tdep = gdbarch_tdep (get_frame_arch 
> (next_frame));
>
>   if (frame_pc_unwind (next_frame)
>       > frame_unwind_register_unsigned (next_frame, SP_REGNUM))
>     /* Assume anything that is vaguely on the stack is a signal
>        trampoline.  */
>     return &ppc_linux_sigtramp_unwind;
>   else
>     return NULL;
> }
>
> Essentially it says that any time the program counter is above the 
> stack pointer, we must be in a signal trampoline, and so GDB proceeds 
> to grope about for a struct rt_sigframe on the stack.
>
> This is not a good assumption. I'm using a GDB stub to debug Xen, and 
> as it so happens, the Xen stack is below the Xen text. That means that 
> the above test always triggers, but of course there is no rt_sigframe 
> on the stack, and my backtrace runs away.

FYI: I looked at a GDB snapshot (gdb-6.3.50.20050818) and the problem 
had been resolved.

-Hollis