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

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 19 August 2009 08:23:54, Jakob Engblom wrote:
> > # Create an empty file named site.exp.
> > # Create a directory named boards in the same location as site.exp.
> > # Create a file named native-gdbserver.exp in the boards directory (see
> below).
> > # Set the DEJAGNU environment variable to point to the empty site.exp.
> > # Run the testsuite with make check-gdb RUNTESTFLAGS="--target_board native-
> > gdbserver".
> 
> Should such files be part of the gdb source tree, so that the tests for reverse
> can be run without having to set up a local special board?

For the generic reverse execution tests --- reverse step, reverse next,
reverse continue, run to breakpoint in reverse, etc., etc., I'd must prefer
that we would get rid of the need for board files at all.  :-)

 1. for native targets, the only reverse solution we currently support is
 precord.  I can't see why we can't default to testing the reverse tests
 with precord then.  We could still leave the possibility of a dejagnu
 board variable changing this defaulting, but I don't think we need
 it currently.  Of course, this would be filtered on selected targets.
 Something along these lines in testsuite/lib/gdb.exp:

proc run_reverse_tests_with_precord {} {

  # Board requested it explicitly.  Might want to try
  # precord against gdbserver.
  if [target_info exists gdb,use_precord] {
    return 1
  }

  if { [isnative] && ([istarget "i?86-*-linux*"] || [istarget "x86_64-*-linux*"]) } then {
    # Nothing else supports precord, yet.
    return 1
  }

  # Nope, don't use precord.  Maybe the target supports reverse
  # debugging in some other way (e.g., a remote full system emulator)
  return 0
}

Then have the tests check run_reverse_tests_with_precord instead of
checking "target_info exists gdb,use_precord".


 2. for remove targets, it would be much much better if the remote target
 reported support for reverse upfront, but, that was never added to the
 protocol ...  Failing that, I still think that a simple probing test
 would work (try a simple reverse step, and if that fails either claiming
 the target doesn't support the command, or, it moved forward instead
 of backwards, then skip all other reverse tests).

This way, everyone runs the reverse tests when they do a simple "make check",
and we get much better test coverage.  As is, only a couple people are
running them, as you have to request them explicitly.

-- 
Pedro Alves