From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24056 invoked by alias); 23 Aug 2002 18:12:45 -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 24048 invoked from network); 23 Aug 2002 18:12:45 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 23 Aug 2002 18:12:45 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17iIvO-0001kJ-00; Fri, 23 Aug 2002 13:12:46 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17iIw5-0005ZM-00; Fri, 23 Aug 2002 14:13:29 -0400 Date: Fri, 23 Aug 2002 11:27:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [RFC] breakpoints and function prologues... Message-ID: <20020823181328.GA21035@nevyn.them.org> Mail-Followup-To: Michael Snyder , Andrew Cagney , gdb-patches@sources.redhat.com References: <6AF1E816-A97C-11D6-B045-00039379E320@> <3D5B42B9.6070201@ges.redhat.com> <20020815135338.GA22990@nevyn.them.org> <3D656658.9D01C76D@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D656658.9D01C76D@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00758.txt.bz2 On Thu, Aug 22, 2002 at 03:31:52PM -0700, Michael Snyder wrote: > Daniel Jacobowitz wrote: > > > > On Thu, Aug 15, 2002 at 01:57:13AM -0400, Andrew Cagney wrote: > > > >I agree with Jim here. I think most folks are actually surprised to find > > > >that if they break on the "{" beginning a function (or indeed anywhere > > > >before the first executable line of code) then their backtrace will not be > > > >correct. Understanding why this is so requires you to "pay attention to > > > >the man behind the curtain", and that we breaks the illusion that source > > > >code maps straight-forwardly onto the running program. Where this extra > > > >knowledge is helpful (like when debugging optimized code) it is fine to > > > >require folks to have it. But here, where it really doesn't do any good, > > > >I think it is just confusing. And, of course, it causes big heartburn for > > > >GUIs the varobj code, as I said earlier. > > > > > > > >I doubt that "{" breaks on the prologue is a crucial feature of gdb, and > > > >given that there are other ways to do this, I don't think it is really > > > >worth supporting... > > > > > > Michael is right here. If a CLI user sets a breakpoint on a line (with > > > code) then that user clearly wants the breakpoint set on that line. > > > > Sure, if the user knows there's code there. I don't think most of our > > users would understand that there is code on the "{", or what it is > > for - > > I suspect that this is a result of a changing user base. > There are more and more users who don't know a lot about > how things work "under the hood". Absolutely. > > and I don't think that breaking by line number should break on > > code inserted by the compiler rather than the user. > > The question is, is there a strong reason to change a behavior > that has been consistent for a very long time (even if undocumented). > Even if the ability to debug the prologue is un-important for most > users, it is important to some, and those users (GCC developers, > for instance) may be quite accustomed to the current behavior. > I am, for instance... I believe there's a strong reason; the change in our user base means that this confuses more people than it helps. Most or all of the people who need to look at the beginning of prologues know about "break *foo". > > > > So I have to agree with Jim (both Jims, I think?). > > > > > If an architecture can't unwind the frame for that breakpoint address > > > then that is a bug in the architecture and/or GDB. The main reason the > > > average prologue analyzer doesn't handle breakpoints in the prologue is, > > > I think, more a factor of not being tested then of being ``hard''. > > > > Most of our ports don't support it, however. > > Most of mine do. Enough to provide frame information for local variables and stack arguments at that point? I didn't think that was the case. Without using CFI or a much more sophisticated prologue analysis mechanism, I don't see how it could be... but I could certainly be wrong :) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer