From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7134 invoked by alias); 1 Mar 2004 02:47:13 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7115 invoked from network); 1 Mar 2004 02:47:12 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 1 Mar 2004 02:47:12 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AxdSZ-0007HQ-Q0; Sun, 29 Feb 2004 21:47:11 -0500 Date: Mon, 01 Mar 2004 02:47:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jason R Thorpe , gdb-patches@sources.redhat.com Subject: Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder Message-ID: <20040301024711.GA27915@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jason R Thorpe , gdb-patches@sources.redhat.com References: <40428C58.1020506@gnu.org> <20040301012656.GA16265@nevyn.them.org> <404292D7.9040100@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404292D7.9040100@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03.o/txt/msg00006.txt On Sun, Feb 29, 2004 at 08:33:11PM -0500, Andrew Cagney wrote: > >On Sun, Feb 29, 2004 at 08:05:28PM -0500, Andrew Cagney wrote: > > > >>>It appears to work (but doesn't have much effect without an rs6000 > >>>unwinder). > >>> > >>>One question (and to follow up my earlier post) is there a better way of > >>>doing this: > >>> > >>>+ if (frame_pc_unwind (next_frame) > 0x7f000000) > >>>+ /* Assume anything that is vaguely on the stack is a signal > >>>+ trampoline. */ > >>>+ return &ppcnbsd_sigtramp_unwind; > >>> > >>>ok?, eventually for 6.1? > > > > > >For other targets, we grub in the code for the sigtramp instruction > >sequence. I'm betting it's fixed for NetBSD too? ppc_linux_in_sigtramp > >does this. > > That's potentially expensive - there should also be a predicate like the > above before the stack is read checked. Then you risk both sigaltstack and thread support. Thread stacks can end up literally anywhere - and do! It might be possible to compare to the current stack pointer, if you're convinced the sigreturn sequence will remain on the stack. I don't know anything about NetBSD - for e.g. i386 GNU/Linux, this isn't necessarily true, but that's handled specially. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7134 invoked by alias); 1 Mar 2004 02:47:13 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7115 invoked from network); 1 Mar 2004 02:47:12 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 1 Mar 2004 02:47:12 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AxdSZ-0007HQ-Q0; Sun, 29 Feb 2004 21:47:11 -0500 Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jason R Thorpe , gdb-patches@sources.redhat.com Subject: Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder Message-ID: <20040301024711.GA27915@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jason R Thorpe , gdb-patches@sources.redhat.com References: <40428C58.1020506@gnu.org> <20040301012656.GA16265@nevyn.them.org> <404292D7.9040100@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404292D7.9040100@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00006.txt.bz2 Message-ID: <20040319000900.pMTDKkdICw-k4lLKdKbxzFabLeGYw9ixTCMTojdSxn0@z> On Sun, Feb 29, 2004 at 08:33:11PM -0500, Andrew Cagney wrote: > >On Sun, Feb 29, 2004 at 08:05:28PM -0500, Andrew Cagney wrote: > > > >>>It appears to work (but doesn't have much effect without an rs6000 > >>>unwinder). > >>> > >>>One question (and to follow up my earlier post) is there a better way of > >>>doing this: > >>> > >>>+ if (frame_pc_unwind (next_frame) > 0x7f000000) > >>>+ /* Assume anything that is vaguely on the stack is a signal > >>>+ trampoline. */ > >>>+ return &ppcnbsd_sigtramp_unwind; > >>> > >>>ok?, eventually for 6.1? > > > > > >For other targets, we grub in the code for the sigtramp instruction > >sequence. I'm betting it's fixed for NetBSD too? ppc_linux_in_sigtramp > >does this. > > That's potentially expensive - there should also be a predicate like the > above before the stack is read checked. Then you risk both sigaltstack and thread support. Thread stacks can end up literally anywhere - and do! It might be possible to compare to the current stack pointer, if you're convinced the sigreturn sequence will remain on the stack. I don't know anything about NetBSD - for e.g. i386 GNU/Linux, this isn't necessarily true, but that's handled specially. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer