From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13720 invoked by alias); 9 Nov 2004 14:35:06 -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 13685 invoked from network); 9 Nov 2004 14:35:00 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 9 Nov 2004 14:35:00 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CRX5I-00027F-5M; Tue, 09 Nov 2004 09:35:00 -0500 Date: Tue, 09 Nov 2004 14:51:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: [RFC] Is skip_prologue_using_sal actually usable? Message-ID: <20041109143459.GA7930@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb@sources.redhat.com References: <200411071355.iA7DtfTE002934@elgar.sibelius.xs4all.nl> <20041109024314.GA1997@nevyn.them.org> <200411091353.iA9DrKjH090730@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411091353.iA9DrKjH090730@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00080.txt.bz2 On Tue, Nov 09, 2004 at 02:53:20PM +0100, Mark Kettenis wrote: > Date: Mon, 8 Nov 2004 21:43:14 -0500 > From: Daniel Jacobowitz > > If you want the first instruction that is not part of the prologue, > then you have no more reason to skip prologues at all. My > understanding is that prologue skipping accomplishes two things: > > B? - Get the arguments into their save slots so that we can find > and display them. > > A? - Get the frame pointer into a sane state so we can backtrace. > > Well, we've taken care of (A) already - the new frame code requires > being able to backtrace from the first instruction of a function, > and we do it. (I think we fall down more often in the epilogue than we > do in the prologue now.) > > Assuming the second point is (A) and the first one is (B): Oops -) Yes, that's what I meant. > Although it sounds plausible I think it's something we should revisit > when GDB actually supports "locations" properly. > > In the mean time, we really should strive for some consistency in > where we put function breakpoints. What do you think about my > statement that too early is better than to late? I don't think I agree. We used to have a lot of problems with placing breakpoints after branches; that, obviously, is too late (excepting the PIC register setup). But I find the inaccuracy of displayed function arguments to be my single biggest day-to-day problem in using GDB. Just moments ago I wasted a couple minutes discovering that a pointer hadn't been saved to the stack yet. -- Daniel Jacobowitz