Re: Question about ppc reverse stepping

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Anthony Green wrote:

> solib-reverse.exp has an executable with undebuggable shared libraries.
> The test is written such that it expects reverse stepping over calls to
> the solib to skip the call completely.  However, on ppc linux, reverse
> stepping has me stepping through some glue magic before popping out the
> other end.  In the text below, when I'm on line 46, the test case
> expects that reverse-step lands me on line 44 (at the bottom) without
> all of the intermediate steps.
> 
> 46	  return 0;			/* end part one */
> (gdb) reverse-step
> 0x00003fffb7fb08b8 in .shr1 () from /home/green/binutils-gdb/gdb/testsuite/gdb.reverse/shr1.sl
> (gdb) reverse-step
> Single stepping until exit from function .shr1,
> which has no line number information.
> 0x00003fffb7fb08b0 in .shr1 () from /home/green/binutils-gdb/gdb/testsuite/gdb.reverse/shr1.sl
> (gdb) reverse-step
> Single stepping until exit from function .shr1,
> which has no line number information.
> 0x0000000010000638 in 00000011.plt_call.shr1+0 ()
> (gdb) reverse-step
> Single stepping until exit from function 00000011.plt_call.shr1+0,
> which has no line number information.
> main () at ./gdb.reverse/solib-reverse.c:44
> 44	  shr1 ("message 3\n");		/* shr1 three */
> 
> Is this what we really want?  Or can I modify the test to repeatedly
> step over the .shr1 lines?

No, the test case is fine as is.  When doing a "step" on line 44, you get
directly to line 46 since "shr1" has no debug info.  This means that
doing a reverse-step on line 46 should get you directly to line 44.

There is code in infrun.c that is supposed to achieve that.  You'll need
to figure out why that doesn't work on ppc at the moment.  What does the
output from "set debug infrun 1" say?

This should be handled in infrun.c starting around line 4746:

      if (debug_infrun)
         fprintf_unfiltered (gdb_stdlog, "infrun: stepped into subroutine\n");

and then:
     if (execution_direction == EXEC_REVERSE)
        {
          /* If we're already at the start of the function, we've either just
             stepped backward into a single instruction function without line
             number info, or stepped back out of a signal handler to the first
             instruction of the function without line number info.  Just keep
             going, which will single-step back to the caller.  */
          if (ecs->stop_func_start != stop_pc)
            {
              /* Set a breakpoint at callee's start address.
                 From there we can step once and be back in the caller.  */
              struct symtab_and_line sr_sal;

              init_sal (&sr_sal);
              sr_sal.pc = ecs->stop_func_start;
              sr_sal.pspace = get_frame_program_space (frame);
              insert_step_resume_breakpoint_at_sal (gdbarch,
                                                    sr_sal, null_frame_id);
            }

The insert_step_resume_breakpoint_at_sal should cause the debugger to
continue backwards until the call to shr1.

Skipping the PLT stub code may be a different issue, that is supposed to
work via the gdbarch_skip_trampoline_code callback; maybe there's something
in the ppc version of that callback that isn't right for reverse debugging.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com