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

[Michael Snyder <msnyder at vmware dot com>]

Jakob Engblom wrote:
> > Hello Jakob -- welcome back!
> >
> > Pedro's reply below includes answers to most of your questions.
> > This is some background.
> >
> > It is normal for those of us doing development on new or
> > unusual platforms to need to define a "board description file",
> > to let Dejagnu know how to do certain things with our target.
> > See "site.exp" in Pedro's email.
>
> Thanks! Obviously, we had no idea at all of this. 
>
> However, we are not really developing a new platform here. We are just doing MI
> comamnds for reverse that should work on any reversible platform.  Therefore, it
> would be nice to generalize reverse to be independent of the particular
> implementation. 
>
> But I get the sense here that process record is a bit too special or convoluted
> to serve as a general reversible platform. It seems that the recording process
> is shining through, in some way. Is that right?

The recording process is visible, yes -- process record is
implemented entirely within gdb, so the command to start making
a recording is given from within gdb.

I think with your setup, you can make the recording first,
before you ever start gdb, am I right?

I don't know whether you also have an option to start making
the recording after you start debugging?  If so, you might want
to test it in the same context?

> > For the reverse debugging tests, I used this guard variable
> > to make sure the tests would only run on targets that were
> > explicitly tagged as being reverse-capable:
> >
> >      if ![target_info exists gdb,can_reverse] {
> >          return
> >      }
>
> That makes sense.  So here we need a board file to say that our native
> record/replay is reversible. 
>
> > So you will want to have this in your board description file:
> >
> >      set_board_info gdb,can_reverse 1
> >
> > Secondly, there are a few commands that are specific to
> > "process record", so I guarded them with this variable:
> >  
> >      if [target_info exists gdb,use_precord] {
> >          # Activate process record/replay
> >          gdb_test "record" "" "Turn on process record"
> >      }
>
> Do any of these need MI equivalents...
>
> > You won't want to use those commands, so you will
> > not define that variable in your board description.
>
> Will you do MI for them then? :)
>
> > If there are any commands that are unique to your
> > implementation, you can define your own guard variable
> > and add them to the tests.
>
> There should not be. We want Simics to be like any other reversible target, and
> the MI command set we are trying to do tests for should as I say be general to
> any reversible target. 
>
>
> Best regards,
>
> /jakob
>
> _______________________________________________________
>
> Jakob Engblom, PhD, Technical Marketing Manager
>
> Virtutech                   Direct: +46 8 690 07 47   
> Drottningholmsvägen 22      Mobile: +46 709 242 646  
> 11243 Stockholm             Web:    www.virtutech.com 
> Sweden
> ________________________________________________________
>