From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1780 invoked by alias); 9 Jan 2008 20:25:05 -0000 Received: (qmail 1756 invoked by uid 22791); 9 Jan 2008 20:25:04 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Jan 2008 20:24:47 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 0393B3CB81; Wed, 9 Jan 2008 12:24:44 -0800 (PST) Subject: Re: [RFC/RFA?] Should break FILE:LINENO skip prologue? From: Michael Snyder To: Joel Brobecker Cc: gdb-patches@sourceware.org In-Reply-To: <20080109151745.GA13181@adacore.com> References: <20080109151745.GA13181@adacore.com> Content-Type: text/plain Date: Wed, 09 Jan 2008 20:25:00 -0000 Message-Id: <1199910284.14654.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00217.txt.bz2 OK, I'll be the devil's advocate. By habit and actual practice, if I tell gdb to set a breakpoint at the opening brace of a function, it is because I want it to stop before the prologue. If I tell gdb to set a breakpoint AFTER local variable x is initialized, but BEFORE local variable y is initialized, as in the following example... int foo() { int x = 12; char *y = "bar"; it is because I want gdb to stop after x is initialized and before y is initialized. If gdb decided not to LET me stop in the middle of the prologue, I would be exceedingly pissed off. On Wed, 2008-01-09 at 07:17 -0800, Joel Brobecker wrote: > Hello, > > I would like to revive a discussion that started sometime in 2002. > The idea is the following: When breaking on a given source line, if > that line is inside a function prologue, skip the prologue (using > the linetable to do so). > > In our experience, we have found that most users are not aware of > the existence of function prologues. When they break on the line > where a function is defined, they think the debugger is doing the > same thing than it would do if it inserted the breakpoint using > that function name. Unfortunately, it doesn't and they end up > having problems trying to print parameter values [1]. > > When we discussed this back in 2002, there wasn't an overwhelming > support for this proposal, but I think that we had mild support. > Both Apple and AdaCore have decided to implement this, and JimB > was also supporting the idea. I searched the archives, and I didn't > really find any negative support. I personally think that it's > friendlier and is usually what the typical user expects. > > The only counter argument, IMO, is the fact that we're changing a > behavior that has been there for a long time... But the current > behavior is currently undocumented (or at least it wasn't in 2002 > :-), and users can use the "break *FUNC_NAME" syntax if they don't > want the prologue to be skipped. Like Jim, I think this syntax > makes better sense - in fact, I have always naturally used the > *FUNC_NAME syntax in these cases, never really used line numbers. > > So I am making this proposal again, with the hope of reaching > a decision, either yes or no. Or, as a compromise, we can control > the behavior through as setting. I would argue for the default value > to change the behavior, since: Deliberately breaking inside the > prologue is a relatively uncommon operation; and the users who expect > to break inside the prologue know what they are doing and will quickly > find a way around. > > Here is a prototype that implements the proposal without the switch. > Surprisingly, the code has evolved in a way that it is now very > easy to implement. Adding the switch would be very simple too. > > 2008-01-09 Joel Brobecker > > * breakpoint.c (skip_prologue_sal): New function. > (resolve_sal_pc): Adjust SAL past prologue if the SAL was > computed from a line number. > > I can write a dedicated testcase or test for this, but I don't think > this will be necessary. A couple of testcases (ending-run.exp and > mi-break.exp) insert breakpoints on the line where a function is > defined, so they already test that this patch has some effect > (understand the testcases will need to be adjusted or they will > have some FAILS). > > Tested on x86-linux. All the changes in the testsuite are expected. > > Thoughts? > > Thanks,