Re: gdb reverse execution: how to actually run tests for it?

[Pedro Alves <pedro@codesourcery.com>]

On Monday 17 August 2009 16:31:19, Hui Zhu wrote:
> > How bad is the failure mode in the reverse tests if the target
> > does not support reverse at all?  Can't we try a simple
> > probing-for-support reverse test and if that fails skip the
> > rest of the reverse tests?  That would likely get rid of all
> > the current needs for a hacked board file.
> >
> > --
> > Pedro Alves
> >
> 
> It will be very helpful.
> 
> If the target don't support reverse,  it will out like:
> (gdb) rc
> Target child does not support this command.

That's a native target ("child").  I don't think you'll get that
error currently against *remote* targets.  Looking at remote.c:remote_resume,
I think a reverse-continue command against gdbserver will
end up sending a regular forward-direction "vCont" packet, so the
remote inferior will execute *forward* instead of reverse... 

Oh well, it's easy to try.  Here it goes:

 $./gdbserver :9999 ./gdbserver
 ./gdb ./gdbserver/gdbserver
 (gdb) tar remote :9999
 (gdb) b main
 (gdb) c
 1884      char **next_arg = &argv[1];
 (gdb) reverse-step
 1885      int multi_mode = 0;

If you disable the vCont packet, with "set remote verbose-resume-packet off",
then GDB will indeed send the correct back-step or back-continue
("bs"/"bc") packets, but, those will be ignored by gdbserver...  You'll end
up with a broken debug session if you try this:

 1884      char **next_arg = &argv[1];
 (gdb) set remote verbose-resume-packet off
 (gdb) reverse-step
 warning: Invalid remote reply:
 <gdb hangs>
 <ctrl-c>
 <ctrl-c>
 Interrupted while waiting for the program.
 Give up (and stop debugging it)? (y or n)

...

It's really much better if the target reports
support or not upfront, so that GDB doesn't even *try* anything
reverse if the target does not support it.

-- 
Pedro Alves