From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19147 invoked by alias); 22 Aug 2002 22:31:54 -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 19136 invoked from network); 22 Aug 2002 22:31:53 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 22 Aug 2002 22:31:53 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA07911; Thu, 22 Aug 2002 15:26:01 -0700 (PDT) Message-ID: <3D656658.9D01C76D@redhat.com> Date: Thu, 22 Aug 2002 15:33:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [RFC] breakpoints and function prologues... References: <6AF1E816-A97C-11D6-B045-00039379E320@> <3D5B42B9.6070201@ges.redhat.com> <20020815135338.GA22990@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00731.txt.bz2 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". > 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... > 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.