From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ac131313@redhat.com>
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Received: (qmail 13476 invoked from network); 10 Jan 2003 15:54:44 -0000
Received: from unknown (HELO localhost.redhat.com) (216.138.202.10)
  by 209.249.29.67 with SMTP; 10 Jan 2003 15:54:44 -0000
Received: from redhat.com (localhost [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP
	id 6F7B83E02; Fri, 10 Jan 2003 10:54:33 -0500 (EST)
Message-ID: <3E1EECB9.9060900@redhat.com>
Date: Fri, 10 Jan 2003 15:54:00 -0000
From: Andrew Cagney <ac131313@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jim Ingham <jingham@apple.com>
Cc: gdb@sources.redhat.com
Subject: Revamped frame chain, useful for PPC?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2003-01/txt/msg00165.txt.bz2

Jim,

Long long ago you mentioned that, to improve performance, you hacked the 
PPC code and core GDB so that it could do a light weight frame chain. 
That is, instead of a full frame prologue (aka, init frame saved regs / 
init extra frame info), it would just chain the frame pointer.

Can I suggest looking at the cagney-unwind-20030108-branch as it 
contains the revamped unwind mechanism.  In particular, it now leaves it 
to the target architecture to determine if/when additional prologue 
analysis should be performed.

See the function get_prev_frame() for the unwind sequence, and 
sentinel-frame / dummy-frame for specific frame implementations.

Andrew