This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]