From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1569 invoked by alias); 15 Apr 2002 07:59:35 -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 1511 invoked from network); 15 Apr 2002 07:59:31 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 15 Apr 2002 07:59:31 -0000 Received: from romulus.sfbay.redhat.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id AAA22646; Mon, 15 Apr 2002 00:59:28 -0700 (PDT) Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g3F7xMb24484; Mon, 15 Apr 2002 00:59:22 -0700 Date: Mon, 15 Apr 2002 00:59:00 -0000 From: Kevin Buettner Message-Id: <1020415075921.ZM24483@localhost.localdomain> In-Reply-To: Andrew Cagney "[patch/rfa:rs6000] Don't use ->prev" (Apr 14, 12:52pm) References: <3CB9B3B1.90007@cygnus.com> To: Andrew Cagney , gdb-patches@sources.redhat.com, Kevin Buettner Subject: Re: [patch/rfa:rs6000] Don't use ->prev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00532.txt.bz2 On Apr 14, 12:52pm, Andrew Cagney wrote: > The rs6000 has me puzzled. I think the ->frame contains the address of > the wrong end of the frame! If ->frame pointed at the frame's start, > the code below wouldn't even be needed. Anyway, I've changed it to use > frame_chain() (I don't see regressions on NetBSD/PPC. The other > possability would be to risk a (recursive) get_prev_frame() call. > > Anyway, is the rs6000 ok? > [...] > * rs6000-tdep.c (frame_get_saved_regs): Use rs6000_frame_chain() > instead of ->prev. I think that your patch is okay so long as you use FRAME_CHAIN() instead of rs6000_frame_chain(). Note that FRAME_CHAIN() may be set to something other than rs6000_frame_chain() depending upon the ABI / OS. At the moment though, it doesn't really matter too much since the case -- signal handler trampolines -- that calling FRAME_CHAIN gets right is broken in frame_get_saved_regs() anyway. The Linux/PPC target works around this deficiency by interposing some code which computes the correct saved register locations for signal handler callers instead of calling the rs6000_* version which invokes rs6000_get_saved_register(). Kevin