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

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

[William Tambe]

I having an issue where the gdb command "next" wrongly work as the
command "step", in that it will step-into functions instead of
stepping-over functions.

To support single stepping I have implemnted set_gdbarch_software_single_step().

Is there another function that I need to implement to support
stepping-over functions ?

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

[Jan Kratochvil]

On Sun, 18 Aug 2019 05:36:34 +0200, William Tambe wrote:
> I having an issue where the gdb command "next" wrongly work as the
> command "step", in that it will step-into functions instead of
> stepping-over functions.
> 
> To support single stepping I have implemnted set_gdbarch_software_single_step().
> 
> Is there another function that I need to implement to support
> stepping-over functions ?

"next" needs properly implemented backtrace/unwinding so that can it can do
"finish" when "next" detects it stepped into a function.


Jan

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

[William Tambe]

On Sat, Aug 17, 2019 at 11:16 PM Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
>
> On Sun, 18 Aug 2019 05:36:34 +0200, William Tambe wrote:
> > I having an issue where the gdb command "next" wrongly work as the
> > command "step", in that it will step-into functions instead of
> > stepping-over functions.
> >
> > To support single stepping I have implemnted set_gdbarch_software_single_step().
> >
> > Is there another function that I need to implement to support
> > stepping-over functions ?
>
> "next" needs properly implemented backtrace/unwinding so that can it can do
> "finish" when "next" detects it stepped into a function.

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 ?

Alternatively, what function within the gdb code implement "next" and "finish" ?

>
>
> Jan

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

[Jan Kratochvil]

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.


Jan

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

[William Tambe]

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.

Within the single-step function gdbarch_software_single_step_ftype()
is there a way to tell whether GDB is stepping-into or stepping-over a
function ?

In fact within my implementation of
gdbarch_software_single_step_ftype() when the instruction
jump-and-link (used when calling a function) is decoded, the
breakpoint is placed at the jump target; I could instead place the
breakpoint after the instruction jump-and-link if I could tell whether
the GDB command "step"/"stepi" or "next"/"nexti" was used.

So within gdbarch_software_single_step_ftype(), is there a way to tell
whether GDB is stepping-into or stepping-over a function ?

>
> Jan

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

[Pedro Alves]

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.

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

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

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

[William Tambe]

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

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

[William Tambe]

Please see below, less noisy GDB output showing a working backtrace
where I can see the caller in frame #1; but yet GDB command "next" is
working as though it was "step"; any suggestion where else I could
look ?

(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);

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

(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



On Fri, Aug 23, 2019 at 10:36 PM William Tambe <tambewilliam@gmail.com> wrote:
>
> 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