From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27921 invoked by alias); 9 Jan 2008 15:18:15 -0000 Received: (qmail 27913 invoked by uid 22791); 9 Jan 2008 15:18:13 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Jan 2008 15:17:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 6654A2A96BD for ; Wed, 9 Jan 2008 10:17:54 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KftgT7y4xtBU for ; Wed, 9 Jan 2008 10:17:54 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A698F2A96BB for ; Wed, 9 Jan 2008 10:17:52 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 44B24E7ACB; Wed, 9 Jan 2008 07:17:45 -0800 (PST) Date: Wed, 09 Jan 2008 15:18:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: [RFC/RFA?] Should break FILE:LINENO skip prologue? Message-ID: <20080109151745.GA13181@adacore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i 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/msg00186.txt.bz2 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 2936 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, -- Joel [1]: I think we have made some progress with parameter/variable tracking with DWARF, but I think it's not activated by default and we also still support platforms where DWARF is not available. --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="skip-prologue.diff" Content-length: 1275 Index: breakpoint.c =================================================================== --- breakpoint.c (revision 117) +++ breakpoint.c (revision 118) @@ -5446,6 +5446,25 @@ gdb_breakpoint (char *address, char *con 0); } +/* Adjust SAL to the first instruction past the function prologue. + The end of the prologue is determined using the line table from + the debugging information. + + If SAL is already past the prologue, then do nothing. */ + +static void +skip_prologue_sal (struct symtab_and_line *sal) +{ + struct symbol *sym = find_pc_function (sal->pc); + struct symtab_and_line start_sal; + + if (sym == NULL) + return; + + start_sal = find_function_start_sal (sym, 1); + if (sal->pc < start_sal.pc) + *sal = start_sal; +} /* Helper function for break_command_1 and disassemble_command. */ @@ -5460,6 +5479,11 @@ resolve_sal_pc (struct symtab_and_line * error (_("No line %d in file \"%s\"."), sal->line, sal->symtab->filename); sal->pc = pc; + + /* If this SAL corresponds to a breakpoint inserted using + a line number, then skip the function prologue if necessary. */ + if (sal->explicit_line) + skip_prologue_sal (sal); } if (sal->section == 0 && sal->symtab != NULL) --1yeeQ81UyVL57Vl7--