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

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

[Pedro Alves]

On 8/25/19 8:04 PM, William Tambe wrote:
> 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 ?

- You'll just have to debug gdb.  Try to figure out why this code, inside
  the "infrun: stepped into subroutine" block,seemingly isn't being reached:

	/* Set a breakpoint at callee's return address (the address
	   at which the caller will resume).  */
	insert_step_resume_breakpoint_at_caller (frame);

- I'd use "nexti" instead of "next" to try stepping over the
  instruction that calls the subroutine, just to make it easier
  to debug what goes wrong.

Thanks,
Pedro Alves

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

[William Tambe]

On Mon, Aug 26, 2019 at 8:18 AM Pedro Alves <palves@redhat.com> wrote:
>
> On 8/25/19 8:04 PM, William Tambe wrote:
> > 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 ?
>
> - You'll just have to debug gdb.  Try to figure out why this code, inside
>   the "infrun: stepped into subroutine" block,seemingly isn't being reached:
>
>         /* Set a breakpoint at callee's return address (the address
>            at which the caller will resume).  */
>         insert_step_resume_breakpoint_at_caller (frame);
>
> - I'd use "nexti" instead of "next" to try stepping over the
>   instruction that calls the subroutine, just to make it easier
>   to debug what goes wrong.

I have debugged the issue that I am having to be originating from
frame_id_eq(); see below patch that I apply to work-around the issue I
am having; I am sure it is not the fix.

frame_id_eq() is used to check whether two frames are identical, and
in comparing the two frames it will compare whether the two frames
have the same program-counter value.

I caught GDB comparing two identical frames differing only by their
program-counter values; where in one frame, the program-counter value
would be at the first instruction of the line making the
function-call, while in the other frame the program-counter value
would be at the return-address from the function-call.

I will guess that, when "next" is used, GDB does not always use the
frame program-counter value after the jump-and-link instruction within
the line making the function-call, but instead use the frame
program-counter value of the first instruction of the line making
function-call.
To get the program-counter value of a frame, I see GDB calling the
callback function (struct frame_unwind *)->prev_register(); and in my
GDB port, that function returns the program-counter value after the
jump-and-link instruction; I will guess that GDB does not always use
that callback function to get the program-counter value of a frame; in
that case, what would be the other function that GDB uses to get the
program-counter value of a frame ?

As mentioned above, here-after is patch that I apply to work-around
the issue I am having.
Any idea what I am missing in my GDB port such that I wouldn't need
the patch below ?

diff --git a/gdb/frame.c b/gdb/frame.c
index d8b5f819f1..c75f8ead38 100644
--- a/gdb/frame.c
+++ b/gdb/frame.c
@@ -707,10 +707,14 @@ frame_id_eq (struct frame_id l, struct frame_id r)
   else if (l.stack_status != r.stack_status || l.stack_addr != r.stack_addr)
     /* If .stack addresses are different, the frames are different.  */
     eq = 0;
+#if 0
+  // ### Disabled for now; as .code addresses could be
+  // ### different while still being for the same frame.
   else if (l.code_addr_p && r.code_addr_p && l.code_addr != r.code_addr)
     /* An invalid code addr is a wild card.  If .code addresses are
        different, the frames are different.  */
     eq = 0;
+#endif
   else if (l.special_addr_p && r.special_addr_p
           && l.special_addr != r.special_addr)
     /* An invalid special addr is a wild card (or unused).  Otherwise


>
> Thanks,
> Pedro Alves

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

[Andrew Burgess]

* William Tambe <tambewilliam@gmail.com> [2019-09-01 14:05:56 -0500]:

> On Mon, Aug 26, 2019 at 8:18 AM Pedro Alves <palves@redhat.com> wrote:
> >
> > On 8/25/19 8:04 PM, William Tambe wrote:
> > > 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 ?
> >
> > - You'll just have to debug gdb.  Try to figure out why this code, inside
> >   the "infrun: stepped into subroutine" block,seemingly isn't being reached:
> >
> >         /* Set a breakpoint at callee's return address (the address
> >            at which the caller will resume).  */
> >         insert_step_resume_breakpoint_at_caller (frame);
> >
> > - I'd use "nexti" instead of "next" to try stepping over the
> >   instruction that calls the subroutine, just to make it easier
> >   to debug what goes wrong.
> 
> I have debugged the issue that I am having to be originating from
> frame_id_eq(); see below patch that I apply to work-around the issue I
> am having; I am sure it is not the fix.
> 
> frame_id_eq() is used to check whether two frames are identical, and
> in comparing the two frames it will compare whether the two frames
> have the same program-counter value.
> 
> I caught GDB comparing two identical frames differing only by their
> program-counter values; where in one frame, the program-counter value
> would be at the first instruction of the line making the
> function-call, while in the other frame the program-counter value
> would be at the return-address from the function-call.

From this description, my guess is that your bug is in your
implementation of the frame_this_id method.

The frame_id of a function is (basically) made of a $sp and $pc value.
The $sp should be the $sp on entry to the frame (or the frame base
address, which is similar), and the $pc should be for the start of the
function.

It sounds to me (just a guess based on the above) that your
frame_this_id method is just using the current $pc in the frame to
build the frame id.  This would explain the issues you are seeing.

Thanks,
Andrew



> 
> I will guess that, when "next" is used, GDB does not always use the
> frame program-counter value after the jump-and-link instruction within
> the line making the function-call, but instead use the frame
> program-counter value of the first instruction of the line making
> function-call.
> To get the program-counter value of a frame, I see GDB calling the
> callback function (struct frame_unwind *)->prev_register(); and in my
> GDB port, that function returns the program-counter value after the
> jump-and-link instruction; I will guess that GDB does not always use
> that callback function to get the program-counter value of a frame; in
> that case, what would be the other function that GDB uses to get the
> program-counter value of a frame ?
> 
> As mentioned above, here-after is patch that I apply to work-around
> the issue I am having.
> Any idea what I am missing in my GDB port such that I wouldn't need
> the patch below ?
> 
> diff --git a/gdb/frame.c b/gdb/frame.c
> index d8b5f819f1..c75f8ead38 100644
> --- a/gdb/frame.c
> +++ b/gdb/frame.c
> @@ -707,10 +707,14 @@ frame_id_eq (struct frame_id l, struct frame_id r)
>    else if (l.stack_status != r.stack_status || l.stack_addr != r.stack_addr)
>      /* If .stack addresses are different, the frames are different.  */
>      eq = 0;
> +#if 0
> +  // ### Disabled for now; as .code addresses could be
> +  // ### different while still being for the same frame.
>    else if (l.code_addr_p && r.code_addr_p && l.code_addr != r.code_addr)
>      /* An invalid code addr is a wild card.  If .code addresses are
>         different, the frames are different.  */
>      eq = 0;
> +#endif
>    else if (l.special_addr_p && r.special_addr_p
>            && l.special_addr != r.special_addr)
>      /* An invalid special addr is a wild card (or unused).  Otherwise
> 
> 
> >
> > Thanks,
> > Pedro Alves