From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31653 invoked by alias); 16 Aug 2002 02:18:15 -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 31549 invoked from network); 16 Aug 2002 02:18:14 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Aug 2002 02:18:14 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17fWgn-0003ro-00; Thu, 15 Aug 2002 21:18:13 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17fWhD-00072x-00; Thu, 15 Aug 2002 22:18:39 -0400 Date: Thu, 15 Aug 2002 19:18:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jim Ingham , gdb-patches@sources.redhat.com Subject: Re: [RFC] breakpoints and function prologues... Message-ID: <20020816021839.GA27038@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jim Ingham , gdb-patches@sources.redhat.com References: <157B023C-B09E-11D6-BDB5-00039379E320@apple.com> <3D5C4FCB.4070005@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5C4FCB.4070005@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00405.txt.bz2 On Thu, Aug 15, 2002 at 09:05:15PM -0400, Andrew Cagney wrote: > > > >Most users I have talked to think that setting a break on the "{" at the > >beginning of a function means the same thing as setting a breakpoint on > >the function. But that is not the case. "break funcName" is AFTER the > >prologue, "break file: is the true function > >beginning. > > Don't forget that ``break func'' is is going to change. It's going to > go back to the start of the function! > > >However, suppose the user puts his breakpoint on the "{" beginning a > >function (this is what most folks do when they want to break on a function > >generically, BTW.) Then when the IDE stops, it creates the varobjs for > >the local variables, which naively get their frame context from the frame > >pointer (which because we stopped at the beginning of the prologue hasn't > >been updated yet). Then the user steps, and all of the variables fail to > >evaluate correctly, since their frame pointer actually points to the > >previous frame, and there is no such variable in the previous frame... > > That is a bug in gdb. GDB should be using the debug info that lets it > set a breakpoint anywhere in the function. If you are suggesting that someday we'll support accessing local variables using better unwind information and prologue analysis - including for targets where no one has written a better prologue analyzer yet and for debug formats which don't emit terribly good unwind information, which covers most of our targets twice over - then I have to say that ``break func'' _shouldn't_ change. It'd be nice, but I don't think it's realistic. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer