[RFC] breakpoints and function prologues...

[Jim Ingham <jingham@apple.com>]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

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.


[-- Attachment #2: linespec.c.diff --]
[-- Type: application/octet-stream, Size: 1267 bytes --]

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;

[-- Attachment #3: Type: text/plain, Size: 3826 bytes --]



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 <stdio.h>
>           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 <main+24>:  bsr     ra,0x120001158 <hello+8>
>
> 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