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

On Mon, Aug 26, 2019 at 8:18 AM Pedro Alves <[email protected]> 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