From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: PPC64-dev List , Linux PPC Dev From: Hollis Blanchard Date: Thu, 11 Aug 2005 10:54:37 -0500 Subject: GDB backtrace and signal trampolines List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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