From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30475 invoked by alias); 15 Aug 2002 22:26:09 -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 30422 invoked from network); 15 Aug 2002 22:26:08 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by sources.redhat.com with SMTP; 15 Aug 2002 22:26:08 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g7FMQ8F04685 for ; Thu, 15 Aug 2002 15:26:08 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 15 Aug 2002 15:26:07 -0700 Received: from inghji.apple.com (inghji.apple.com [17.201.22.240]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g7FMQ7302545 for ; Thu, 15 Aug 2002 15:26:07 -0700 (PDT) Date: Thu, 15 Aug 2002 15:26:00 -0000 Subject: Re: [RFC] breakpoints and function prologues... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Jim Ingham To: gdb-patches@sources.redhat.com Content-Transfer-Encoding: 7bit In-Reply-To: <1029446396.15888.ezmlm@sources.redhat.com> Message-Id: <157B023C-B09E-11D6-BDB5-00039379E320@apple.com> X-SW-Source: 2002-08/txt/msg00389.txt.bz2 On Thursday, August 15, 2002, at 02:19 PM, gdb-patches-digest-help@sources.redhat.com wrote: > From: Andrew Cagney > Date: Wed Aug 14, 2002 10:57:13 PM US/Pacific > To: gdb-patches@sources.redhat.com > Subject: Re: [RFC] breakpoints and function prologues... > > >> 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. 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. Actually a better representation of the truth is "All the users I have talked to have cussed me out when they found out that these two were not equivalent". > > 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''. > There is another problem that this causes which is again fixable, but harder than getting backtraces right, which I mentioned in a previous note, but is worth repeating. The varobj system, which is by far the best way to store variables in gdb for use in an IDE, needs to know the frame in which it is creating a varobj, when one is made. That is so you can have varobj's for various stack levels at the same time, and when you go to update them, they will update themselves in the correct context. You don't want this to be dependant on frame number since we start numbering at the top of the stack so the same stack frame changes its number over time, but it is very useful to have the varobj's persist till the frame actually goes out of scope. The way the IDE's I have worked on use varobj's is that the user puts a breakpoint somewhere. The IDE stops there, and creates varobj's for each of the local variables, so it can populate its local variables window. Then each time the user steps, the IDE just tells gdb to update the varobj's it has lying around. 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... You could imagine ways to work around this - notice you are in the prologue when you go to make varobj's and either try to disassemble the prologue to figure out what you should do to the frame pointer to make it right (which is not necessarily trivial), or suspend making the varobj's for real till you happen to end up out of the prologue (though then you have to explain to the user why when they first stopped in the function all their local variables have no values...). Or note the error when it occurs and just blindly remake all the varobj's. None of these is very satisfactory... Jim -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer