From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18138 invoked by alias); 1 Aug 2005 20:51:01 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18110 invoked by uid 22791); 1 Aug 2005 20:50:55 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 01 Aug 2005 20:50:55 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1DzhFN-0005DP-Ic; Mon, 01 Aug 2005 16:50:53 -0400 Date: Mon, 01 Aug 2005 20:51:00 -0000 From: Daniel Jacobowitz To: Stefan =?iso-8859-1?Q?Burstr=F6m?= Cc: gdb@sources.redhat.com Subject: Re: rs6000 / ppc backend in gdb Message-ID: <20050801205053.GA19971@nevyn.them.org> Mail-Followup-To: Stefan =?iso-8859-1?Q?Burstr=F6m?= , gdb@sources.redhat.com References: <20050801131203.GA4405@nevyn.them.org> <33e255d0bad.2dcea4ea@mail.m.bonet.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <33e255d0bad.2dcea4ea@mail.m.bonet.se> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-08/txt/msg00005.txt.bz2 On Mon, Aug 01, 2005 at 09:32:59PM +0100, Stefan Burström wrote: > Well, the problem is not when debug info is available. The problem is if the > stack chain goes through the OS where no debug info at all is available. > > I suppose I am pretty much on my own if I want to get this functionality > into GDB? Why can't you use the prologue analyzer in this case? You don't have symbols at the start of functions? Well, in that case, there's not much to be done - what will happen is GDB will find the nearest plausible symbol, decide that's the start of the function, and prologue analyze from there. If that is a frameless function, and the function you're really in isn't frameless, you'll lose. If you have any bright ideas for handling this without breaking the common case, please do share. > One interesting thing about all this is that even if the PPC backend tries > to be really nice and look at the prologue to determine various aspects of > the frame, it still assumes that the previous sp is saved where the current > sp points. Yes, I think that's fairly lame, but I'm not familiar with the PPC backend at all. -- Daniel Jacobowitz CodeSourcery, LLC