From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3318 invoked by alias); 2 Mar 2004 22:48:17 -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 3307 invoked from network); 2 Mar 2004 22:48:16 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 2 Mar 2004 22:48:16 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id F26112B92; Tue, 2 Mar 2004 17:48:11 -0500 (EST) Message-ID: <40450F2B.9000500@gnu.org> Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Kevin Buettner , Jason R Thorpe Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder References: <40428C58.1020506@gnu.org> <20040302152128.1a9b033d@saguaro> In-Reply-To: <20040302152128.1a9b033d@saguaro> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00033.txt.bz2 > On Sun, 29 Feb 2004 20:05:28 -0500 > Andrew Cagney wrote: > > >>> * ppcnbsd-tdep.c: Include "trad-frame.h", and "frame-unwind.h". >>> (struct ppcnbsd_sigtramp_cache, ppcnbsd_sigtramp_this_id) >>> (ppcnbsd_sigtramp_prev_register, ppcnbsd_sigtramp_cache) >>> (ppcnbsd_sigtramp_sniffer, ppcnbsd_sigtramp_unwind) >>> (ppcnbsd_init_abi): Implement a NetBSD/PPC signal trampline >>> unwinder, register. > > > After reading the disucssion, the only part about this which bothers > me is the part that you yourself had a question about: > > >>> + if (frame_pc_unwind (next_frame) > 0x7f000000) >>> + /* Assume anything that is vaguely on the stack is a signal >>> + trampoline. */ >>> + return &ppcnbsd_sigtramp_unwind; > > > Given Mark K's comments, I think it would be better to check for a > specific instruction sequence. I know it's expensive, but it seems > like a more robust approach. (But, also given Mark K's comments, > it seems that a name based approach will work well in the future.) We'd better wait for Jason's input then. Jason will hopefully know exactly what the rules here are - which is better than us all guessing :-) Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3318 invoked by alias); 2 Mar 2004 22:48:17 -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 3307 invoked from network); 2 Mar 2004 22:48:16 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 2 Mar 2004 22:48:16 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id F26112B92; Tue, 2 Mar 2004 17:48:11 -0500 (EST) Message-ID: <40450F2B.9000500@gnu.org> Date: Tue, 02 Mar 2004 22:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Kevin Buettner , Jason R Thorpe Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder References: <40428C58.1020506@gnu.org> <20040302152128.1a9b033d@saguaro> In-Reply-To: <20040302152128.1a9b033d@saguaro> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00033.txt Message-ID: <20040302224800.jXzhiwlffc5t-dkr5CJsj7ioexBEEnmJ6wZhGMt85Yc@z> > On Sun, 29 Feb 2004 20:05:28 -0500 > Andrew Cagney wrote: > > >>> * ppcnbsd-tdep.c: Include "trad-frame.h", and "frame-unwind.h". >>> (struct ppcnbsd_sigtramp_cache, ppcnbsd_sigtramp_this_id) >>> (ppcnbsd_sigtramp_prev_register, ppcnbsd_sigtramp_cache) >>> (ppcnbsd_sigtramp_sniffer, ppcnbsd_sigtramp_unwind) >>> (ppcnbsd_init_abi): Implement a NetBSD/PPC signal trampline >>> unwinder, register. > > > After reading the disucssion, the only part about this which bothers > me is the part that you yourself had a question about: > > >>> + if (frame_pc_unwind (next_frame) > 0x7f000000) >>> + /* Assume anything that is vaguely on the stack is a signal >>> + trampoline. */ >>> + return &ppcnbsd_sigtramp_unwind; > > > Given Mark K's comments, I think it would be better to check for a > specific instruction sequence. I know it's expensive, but it seems > like a more robust approach. (But, also given Mark K's comments, > it seems that a name based approach will work well in the future.) We'd better wait for Jason's input then. Jason will hopefully know exactly what the rules here are - which is better than us all guessing :-) Andrew