From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5087 invoked by alias); 23 Jul 2002 01:18:43 -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 5078 invoked from network); 23 Jul 2002 01:18:42 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by sources.redhat.com with SMTP; 23 Jul 2002 01:18:42 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g6N1Ifk21651 for ; Mon, 22 Jul 2002 18:18:41 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 22 Jul 2002 18:18:02 -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 g6N1IeT05081 for ; Mon, 22 Jul 2002 18:18:40 -0700 (PDT) Date: Mon, 22 Jul 2002 18:54:00 -0000 Subject: [RFC] breakpoints and function prologues... Content-Type: multipart/mixed; boundary=Apple-Mail-4--312204754 Mime-Version: 1.0 (Apple Message framework v539) From: Jim Ingham To: gdb-patches@sources.redhat.com In-Reply-To: <1027384602.26926.ezmlm@sources.redhat.com> Message-Id: <1E541B00-9DDA-11D6-924E-00039379E320@> X-SW-Source: 2002-07/txt/msg00452.txt.bz2 --Apple-Mail-4--312204754 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Content-length: 1617 Joel, I did the same thing for Apple's gdb, and for the same reasons you mentioned. The solution for the GUI is still not perfect, because you end up either moving the breakpoint indicator on them, or you end up stopping at the breakpoint but having the PC marker not be where the breakpoint marker is, both of which are a little disconcerting. Another strong reason for doing this in a GUI is if you are using varobj's to represent variables. The reason for this is that the varobj stores the frame in which it is valid when it is made. If you stop at the beginning of the function and make varobj's for all the local variables (which is the usual mode for a GUI) then the frame that is recorded will be the frame of the previous function ('cause the frame pointer hasn't been moved yet). When you then step into the function, all the varobj's are now out of scope. Oops... At which point somebody needs to be smart enough to guess what has happened, trash all the varobj's and recreate them in the current scope. Not a very good way to go. I solved the problem a little differently, however. The fact is that decode_line_1 takes a funfirstline argument, which is supposed to tell it whether to move the breakpoint past the prologue. But it doesn't look at this argument in the case of setting a file:line breakpoint. So I just made it do that. I like this solution, because it unifies in concept the breakpoint moving done for function symbols and for file:line symbols (though as you see, the actual motion is handled by different pieces of code.) I attached that patch below. --Apple-Mail-4--312204754 Content-Disposition: attachment; filename=linespec.c.diff Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="linespec.c.diff" Content-length: 1267 Index: linespec.c =================================================================== RCS file: /cvs/src/src/gdb/linespec.c,v retrieving revision 1.18 diff -c -w -r1.18 linespec.c *** linespec.c 5 Apr 2002 22:04:41 -0000 1.18 --- linespec.c 23 Jul 2002 01:09:59 -0000 *************** *** 1070,1076 **** --- 1070,1100 ---- if (val.symtab == 0) val.symtab = s; + /* If funfirstline is set, we need to look up the function + containing the line, and move past the prologue. */ + val.pc = 0; + if (funfirstline) + { + CORE_ADDR pc = 0; + + if (find_line_pc (val.symtab, val.line, &pc)) + { + struct symbol *func_sym; + struct symtab_and_line sal; + + func_sym = find_pc_function (pc); + if (func_sym) + { + sal = find_function_start_sal (func_sym, 1); + /* Don't move the line, just set the pc + to the right place. */ + if (val.line <= sal.line) + val.pc = sal.pc; + } + } + } + values.sals = (struct symtab_and_line *) xmalloc (sizeof (struct symtab_and_line)); values.sals[0] = val; --Apple-Mail-4--312204754 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Content-length: 3826 Jim On Monday, July 22, 2002, at 05:36 PM, gdb-patches-digest-help@sources.redhat.com wrote: > > > I would like to have your opinion on the following issue. This is more > spectacular on Tru64, but the idea behind this can be reproduced on any > system. > > Given the following simple program: > 1 #include > 2 > 3 void > 4 hello (void) > 5 { > 6 printf ("Hello world.\n"); > 7 } > 8 > 9 int > 10 main (void) > 11 { > 12 hello (); > 13 return 0; > 14 } > (compiled using "gcc -g hello.c -o hello") > > The program does not stop if I put a breakpoint at line 4 before > running it: > > (gdb) b hello.c:4 > Breakpoint 1 at 0x120001150: file hello.c, line 4. > (gdb) run > Starting program: /usr/prague.a/brobecke/skip_prologue/hello > Hello world. > > Program exited normally. > (gdb) > > On the other hand, if I use the function name to put the breakpoint, > then the program stops: > > (gdb) b hello > Breakpoint 2 at 0x120001168: file hello.c, line 6. > (gdb) run > Starting program: /usr/prague.a/brobecke/skip_prologue/hello > > Breakpoint 2, hello () at hello.c:6 > 6 printf ("Hello world.\n"); > (gdb) > > It is more spectacular in the Tru64 case, because the Tru64 linker > performs some optimization by default that often cause the first few > instructions to be skipped (usually the instruction loading the gp). > A disass in function main() shows this: > > 0x1200011b0 : bsr ra,0x120001158 > > But the problem is a bit more general that this: > > - "break function-name" causes GDB to skip the function prologue > - On the other hand, "break file:line_num" does not cause GDB to skip > the function prologue > > Some of our users have been confused by this, mostly because they use a > graphical front-end where it is so easy to click to put a breakpoint on > a given line that they sometimes don't know or want to know that there > are other ways to insert breakpoints. > > Some of our users thought that breakpoint 1 and 2 above where > equivalent, and where therefore surprised to see that their function > parameters had junk values. Once you know that in case of breakpoint 1, > the prologue has not been executed, it is easy to figure out that the > parameter homing had not taken place yet, hence the incorrect values. > > In our experience, the only case when a user don't want to skip the > function prologue is when doing instruction-level debugging. So, we are > considering changing the behavior of the "break file:line-num" command > to behave like "break function-name", that is slightly offset the > breakpoint address to skip the prologue. > > That will fix the Tru64 problem, and we believe that it will make GDB > more user-friendly by making breakpoint 1 and 2 equivalent. I would > like > to have your opinion on this. > > Interestingly enough, I had made a prototype change that was adding > this > capability to GDB due to another problem (it was a compiler deficiency > that I wanted to work-around in GDB). I never finished this work > because > I convinced myself that it was better to fix the compiler (which, due > to > lack of time, I haven't done yet :-). I am attaching this patch to this > mail just as a reference. It probably needs a bit of dusting off, and > some touch-ups before it is suitable for submission if the GDB > community > like the idea. > > -- > Joel > -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer --Apple-Mail-4--312204754--