From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-31918-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 25836 invoked by alias); 16 May 2008 20:42:27 -0000
Received: (qmail 25828 invoked by uid 22791); 16 May 2008 20:42:26 -0000
X-Spam-Check-By: sourceware.org
Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 16 May 2008 20:42:09 +0000
Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) 	by brahms.sibelius.xs4all.nl (8.14.1/8.14.1) with ESMTP id m4GKg1Sl032753; 	Fri, 16 May 2008 22:42:01 +0200 (CEST)
Received: (from kettenis@localhost) 	by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id m4GKg0Up023579; 	Fri, 16 May 2008 22:42:01 +0200 (CEST)
Date: Fri, 16 May 2008 20:42:00 -0000
Message-Id: <200805162042.m4GKg0Up023579@brahms.sibelius.xs4all.nl>
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: aristovski@qnx.com
CC: gdb@sources.redhat.com
In-reply-to: <482DD704.70808@qnx.com> (message from Aleksandar Ristovski on 	Fri, 16 May 2008 14:48:36 -0400)
Subject: Re: Stepping out of signal handler problem
References: <g0kcje$md5$1@ger.gmane.org> <200805161732.m4GHWcjU013412@brahms.sibelius.xs4all.nl> <482DD704.70808@qnx.com>
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2008-05/txt/msg00136.txt.bz2

> Date: Fri, 16 May 2008 14:48:36 -0400
> From: Aleksandar Ristovski <aristovski@qnx.com>
> 
> Mark Kettenis wrote:
> >> From: Aleksandar Ristovski <aristovski@qnx.com>
> >> Date:  Fri, 16 May 2008 12:26:43 -0400
> >>
> >> This makes question 2: Is the only way to implement this similar to
> >> linux-nat (scanning for sigreturn kernel call)? Is there anything
> >> 'cleaner'?
> > 
> > The clean way of doing this is provide proper unwind info for the
> > signal trampoline.  This shouldn't be too difficult if your signal
> > trampolines live in libc, and quite a bit harder if they are in the
> > kernel.
> > 
> 
> What is the preferred way: frame_unwind_append_sniffer or
> tramp_frame_prepend_unwinder?

Neither.  I was referring to the possibility to generate DWARF2 frame
info for the signal trampoline.  This is what is done in glibc, the
Linux C library.  We also have a test for this in the GDB testsuite
(gdb.arch/i386-signal.c).

The nice thing about this approach is that it avoids hardcoding the
signal frame layout in GDB, making it possible to change the
implementation without having to adjust GDB.