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

[Michael Snyder]

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
> ________________________________________________________
>   
> 
> 
> 
>