This is the mail archive of the 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?

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

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] {

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 Engblom, PhD, Technical Marketing Manager

Virtutech Direct: +46 8 690 07 47 Drottningholmsvägen 22 Mobile: +46 709 242 646 11243 Stockholm Web: Sweden

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