Re: [RFC/RFA] continue stepping if landed in new range of same line

[Joel Brobecker <brobecker@adacore.com>]

> >     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