This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC/RFA] continue stepping if landed in new range of same line
> > void foo (void) { bar (); baz (); }
>
> Amusingly, when you copy and paste this into Emacs, it winds up in
> perfect GNU style on five lines...
I am wondering what emacs would do with the following example:
void increment (int *a, int *b) { *a = *a + 1; *b = *b + 1; }
I wanted to try, but I must be missing something in my setup as
emacs doesn't indent either cases.
> I ran the experiment. With the function on five lines, next goes from
> bar() to baz() and then to }. With the function on one line, it goes
> all the way from bar() back to the caller. So, maybe it was intended
> to handle this case, but it doesn't.
I think that the debugger would need the help of the compiler in order
to be able to do that. With the example above, I get the following code
on x86:
increment:
# f.c:1
.file 1 "f.c"
.loc 1 1 0
pushl %ebp #
movl %esp, %ebp #,
# f.c:1
.loc 1 1 0
movl 8(%ebp), %eax # a, a
movl 12(%ebp), %edx # b, b
incl (%eax) #* a
incl (%edx) #* b
popl %ebp #
ret
As you can see, the compiler repeats line 1 at the first instruction
past the prologue, but that's it. If the compiler had emitted
something a new line 1 at the epilogue, here is what the debugger
would do (does, in fact):
(gdb) run
Starting program: /home/no-backup/brobecke/next/C/g
Breakpoint 1, increment (a=0xbf9dd220, b=0xbf9dd21c) at f.c:1
1 void increment (int *a, int *b) { *a = *a + 1; *b = *b + 1; }
(gdb) n
1 void increment (int *a, int *b) { *a = *a + 1; *b = *b + 1; }
(gdb) x /i $pc
0x80483cd <increment+13>: pop %ebp
On the other hand, explicitly separating the two statements with
an extra line as follow:
# f.c:1
.loc 1 1 0
movl 8(%ebp), %eax # a, a
incl (%eax) #* a
# f.c:1
.loc 1 1 0
movl 12(%ebp), %edx # b, b
incl (%edx) #* b
# f.c:1
.loc 1 1 0
popl %ebp #
ret
Does not allow us to stop before the second statement.
> My best guess is that it was design to handle a single-line function
> without a call, to prevent us from skipping from the prologue all the
> way out. But I think other measures will prevent that too.
That's the part that I am no longer sure I understand. Which scenario
would that be? To me, after having stopped at the beginning of a
procedure, just past the prologue, and doing a next as above.
Right now, with the debugging info that is currently generated,
we do skip the function all the way out. However, if we're inside
the prologue: we do stop at the first instruction first. Maybe
that's what this code is trying to achieve.
Indeed, when I deactived the code that checks for the last line
in our function, here is the new behavior:
(gdb) b *increment
Breakpoint 1 at 0x80483c0: file f.c, line 1.
(gdb) run
Starting program: /home/no-backup/brobecke/next/C/g
Breakpoint 1, increment (a=0xbfd16d60, b=0xbfd16d5c) at f.c:1
1 void increment (int *a, int *b) { *a = *a + 1; *b = *b + 1; }
(gdb) n
main () at g.c:12
12 printf ("a = %d, b = %d\n", a, b);
Before I disabled this code, GDB would stop at line f.c:1 one more
time before landing back in the caller.
Perhaps if this is a requirement, we might want to add a testcase
for it in our testsuite. Optimization is not necessary in order
to reproduce this... Just for kicks, I ran the testsuite with
the disabled code, to see if anything would fail because of it,
and not unexpectedly, nothing did...
--
Joel