From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21567 invoked by alias); 7 Apr 2004 04:48:45 -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 21476 invoked from network); 7 Apr 2004 04:48:39 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 7 Apr 2004 04:48:39 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1BB4zM-0000Yq-KV; Wed, 07 Apr 2004 00:48:36 -0400 Date: Wed, 07 Apr 2004 04:48:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: cagney@gnu.org, gdb@sources.redhat.com Subject: Re: [mips] When to use a proc_desc Message-ID: <20040407044836.GA2108@nevyn.them.org> Mail-Followup-To: Mark Kettenis , cagney@gnu.org, gdb@sources.redhat.com References: <20040325040322.GA12885@nevyn.them.org> <4062FCC4.5080102@gnu.org> <4073279E.2030807@gnu.org> <20040406215810.GA28116@nevyn.them.org> <200404062333.i36NXYtK001226@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404062333.i36NXYtK001226@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-04/txt/msg00051.txt.bz2 On Wed, Apr 07, 2004 at 01:33:34AM +0200, Mark Kettenis wrote: > Date: Tue, 6 Apr 2004 17:58:10 -0400 > From: Daniel Jacobowitz > > On Tue, Apr 06, 2004 at 05:56:46PM -0400, Andrew Cagney wrote: > > >I'll need to study this further, however, look at HP/UX. > > > > > >That unwinder checks its equivalent PDR against the prologue, ticking each > > >register off as it is encountered. > > > > I think the long answer is the same -- look at HP/UX. Fetch the PDR and > > then compare it against the instructions up-to $pc to see how many of > > those stores actually occured. > > I think that defeats the point of having the proc_desc in the first > place. If we're only going to acknowledge register saves that we can > 'easily' find, then why bother reading any of this out of the proc_desc > at all? > > Because it allows one to determine where the prologue actually ends, > which is after all registers described by the descriptor have been > saved. Hmm, you're saying - scan the function until we have seen all the marked registers saved and then stop scanning for more saves? That's interesting, but I'm not sure how useful it is. It's very different from the way we use proc_desc's now. I'll have to think about it. Or just punt, rip out the GAS .pdr support, and add dwarf2 CFI support; it should just be a matter of flipping the switch now. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer