Re: gdb command "next" wrongly working as command "step"

[William Tambe <tambewilliam@gmail.com>]

On Fri, Aug 23, 2019 at 4:54 PM Pedro Alves <palves@redhat.com> wrote:
>
> On 8/23/19 10:33 PM, William Tambe wrote:
> > On Sun, Aug 18, 2019 at 4:06 AM Jan Kratochvil
> > <jan.kratochvil@redhat.com> wrote:
> >> On Sun, 18 Aug 2019 10:31:54 +0200, William Tambe wrote:
> >>> Can I have suggestions of locations within the gdb code where I could
> >>> put breakpoints to trace where the issue I am having is occurring ?
> >> Check what "set debug infrun 1" says and grep the sources for the displayed
> >> messages.
> >>
> > Using "set debug infrun 1", I can see that GDB stops only after
> > printing the following message:
> > infrun: stepped to a different line.
> > When the above event happens, GDB has stepped inside the function,
> > which is obviously going to be on a different line; however, I am
> > expecting GDB to step over the function.
>
> Do a backtrace at this point.  GDB should see the caller in frame #1.
> Sounds like it doesn't.

It does.

My backtrace appear to be working properly.
See below example listing from using "next" at a line where a function
is used; it also show the output of "bt" before and after using
"next".
The decoded instructions is a lot of noise, but I am hoping you could
see that I have a working backtracing, but yet "next" is working as
though it was "step".

(gdb) b _puts_r
Breakpoint 1 at 0x1688: file
../../../../../newlib-cygwin/newlib/libc/stdio/puts.c, line 73.
(gdb) r
Starting program: a.out

Breakpoint 1, _puts_r (ptr=0x8b48 <impure_data>, s=0x7b20 "Hello
World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73
73        size_t c = strlen (s);
c7 2e   => 0x00001688 <_puts_r+24>:     cpy %2, %fp
9f 2c      0x0000168a <_puts_r+26>:     inc8 %2, -4
8c 18      0x0000168c <_puts_r+28>:     li8 %1, 0xc8 # -56
b8 1e      0x0000168e <_puts_r+30>:     add %1, %fp
f2 21      0x00001690 <_puts_r+32>:     st32 %2, %1
c7 1e      0x00001692 <_puts_r+34>:     cpy %1, %fp
9c 1c      0x00001694 <_puts_r+36>:     inc8 %1, -52
ea 11      0x00001696 <_puts_r+38>:     ld32 %1, %1
e0 d0      0x00001698 <_puts_r+40>:     gip %sr
a2 d0 be 01 00 00          0x0000169a <_puts_r+42>:     inc32 %sr, 446
d8 fd      0x000016a0 <_puts_r+48>:     jl %rp, %sr
8c 38      0x000016a2 <_puts_r+50>:     li8 %3, 0xc8 # -56
b8 3e      0x000016a4 <_puts_r+52>:     add %3, %fp
ea 33      0x000016a6 <_puts_r+54>:     ld32 %3, %3
f2 13      0x000016a8 <_puts_r+56>:     st32 %1, %3
(gdb) bt
#0  _puts_r (ptr=0x8b48 <impure_data>, s=0x7b20 "Hello World") at
../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73
#1  0x0000184a in puts (s=0x7b20 "Hello World") at
../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:129
#2  0x0000132e in main (argc=1, argv=0x3fff000) at helloworld.c:5
(gdb) n
strlen (str=0x7b20 "Hello World") at
../../../../../newlib-cygwin/newlib/libc/string/strlen.c:54
54        const char *start = str;
c7 1e   => 0x00001866 <strlen+14>:      cpy %1, %fp
9f 18      0x00001868 <strlen+16>:      inc8 %1, -8
c7 2e      0x0000186a <strlen+18>:      cpy %2, %fp
9f 24      0x0000186c <strlen+20>:      inc8 %2, -12
ea 32      0x0000186e <strlen+22>:      ld32 %3, %2
f2 31      0x00001870 <strlen+24>:      st32 %3, %1
(gdb) bt
#0  strlen (str=0x7b20 "Hello World") at
../../../../../newlib-cygwin/newlib/libc/string/strlen.c:54
#1  0x000016a2 in _puts_r (ptr=0x8b48 <impure_data>, s=0x7b20 "Hello
World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73
#2  0x0000184a in puts (s=0x7b20 "Hello World") at
../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:129
#3  0x0000132e in main (argc=1, argv=0x3fff000) at helloworld.c:5
(gdb)


>
> Or to be more accurate, use "stepi" to step to the first instruction
> of the called function, and run "bt" there.

I have also tried using "stepi" to step to the first instruction of
the called function.
"bt" works correctly.

>
> As Jan said, for "next" to work properly, backtrace/unwinding must work
> properly.  When "next" behaves like "step", the most frequent reason
> is that unwinding is broken.  "next" does a "backtrace" to detect whether
> you've stepped into called function, and if you did, then it continues
> execution to the address where the called function returns.
>
> Thanks,
> Pedro Alves