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

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

[Jakob Engblom]

I am trying to finally implement the reverse ability for MI commands, but
creating and testing the tests is looking challenging. The fundamental issue is
that it seems that I cannot get the regular reverse tests to run, to know how to
properly code the reverse tests for reverse MI. 

When I run

$ make check RUNTESTFLAGS="gdb.reverse/*.exp"

There is a flurry of activity ending in this:

---
                === gdb tests ===

Schedule of variations:
    unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../../src/gdb/testsuite/config/unix.exp as tool-and-target-specific
interface file.
Running ../../../src/gdb/testsuite/gdb.reverse/solib-reverse.exp ...
Running ../../../src/gdb/testsuite/gdb.reverse/step-reverse.exp ...
Running ../../../src/gdb/testsuite/gdb.reverse/until-reverse.exp ...
Running ../../../src/gdb/testsuite/gdb.reverse/break-reverse.exp ...
Running ../../../src/gdb/testsuite/gdb.reverse/finish-reverse.exp ...
Running ../../../src/gdb/testsuite/gdb.reverse/machinestate.exp ...
Running ../../../src/gdb/testsuite/gdb.reverse/consecutive-reverse.exp ...
Running ../../../src/gdb/testsuite/gdb.reverse/watch-reverse.exp ...

                === gdb Summary ===

/home/jakob/gdb7/gdb-host-revpatched/gdb/testsuite/../../gdb/gdb version
6.8.50.20090814-cvs -nw -nx

make[3]: Leaving directory `/home/jakob/gdb7/gdb-host-revpatched/gdb/testsuite'
make[2]: Leaving directory `/home/jakob/gdb7/gdb-host-revpatched/gdb'
make[1]: Nothing to be done for `check-target'.
make[1]: Leaving directory `/home/jakob/gdb7/gdb-host-revpatched'
---

Which seems to indicate that no tests were actually run. This is a 6.8.50 branch
that I checked out of cvs late last week. 

What is required to actually run the reverse tests? Do I need to build my gdb in
any special way?

I suspect that this line the test scripts is the cause of the premature exit
from the tests:

---
if ![target_info exists gdb,can_reverse] {
    return
}
---

So how do I make gdb realize that it can indeed reverse itself?

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
________________________________________________________
  

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

[Hui Zhu]

To use the testsuite of reverse:

cat /usr/share/dejagnu/baseboards/precord.exp
# Testing programs using process record/replay (precord)
load_base_board_description "unix"
set_board_info gdb,can_reverse 1
set_board_info gdb,use_precord 1

make check RUNTESTFLAGS="break-reverse.exp --target_board=precord" &&
make check RUNTESTFLAGS="consecutive-reverse.exp
--target_board=precord" && make check RUNTESTFLAGS="finish-reverse.exp
--target_board=precord" && make check RUNTESTFLAGS="machinestate.exp
--target_board=precord" && make check RUNTESTFLAGS="solib-reverse.exp
--target_board=precord" && make check RUNTESTFLAGS="step-reverse.exp
--target_board=precord" && make check RUNTESTFLAGS="until-reverse.exp
--target_board=precord" && make check RUNTESTFLAGS="watch-reverse.exp
--target_board=precord"

It just test reverse and prec target.  If you want test reverse with
other target, I think you need change follow code in .exp:
runto main

if [target_info exists gdb,use_precord] {
    # Activate process record/replay
    gdb_test "record" "" "Turn on process record"
    # FIXME: command ought to acknowledge, so we can test if it succeeded.
}


Thanks,
Hui


On Mon, Aug 17, 2009 at 15:42, Jakob Engblom<jakob@virtutech.com> wrote:
> I am trying to finally implement the reverse ability for MI commands, but
> creating and testing the tests is looking challenging. The fundamental issue is
> that it seems that I cannot get the regular reverse tests to run, to know how to
> properly code the reverse tests for reverse MI.
>
> When I run
>
> $ make check RUNTESTFLAGS="gdb.reverse/*.exp"
>
> There is a flurry of activity ending in this:
>
> ---
>                === gdb tests ===
>
> Schedule of variations:
>    unix
>
> Running target unix
> Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
> target.
> Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
> Using ../../../src/gdb/testsuite/config/unix.exp as tool-and-target-specific
> interface file.
> Running ../../../src/gdb/testsuite/gdb.reverse/solib-reverse.exp ...
> Running ../../../src/gdb/testsuite/gdb.reverse/step-reverse.exp ...
> Running ../../../src/gdb/testsuite/gdb.reverse/until-reverse.exp ...
> Running ../../../src/gdb/testsuite/gdb.reverse/break-reverse.exp ...
> Running ../../../src/gdb/testsuite/gdb.reverse/finish-reverse.exp ...
> Running ../../../src/gdb/testsuite/gdb.reverse/machinestate.exp ...
> Running ../../../src/gdb/testsuite/gdb.reverse/consecutive-reverse.exp ...
> Running ../../../src/gdb/testsuite/gdb.reverse/watch-reverse.exp ...
>
>                === gdb Summary ===
>
> /home/jakob/gdb7/gdb-host-revpatched/gdb/testsuite/../../gdb/gdb version
> 6.8.50.20090814-cvs -nw -nx
>
> make[3]: Leaving directory `/home/jakob/gdb7/gdb-host-revpatched/gdb/testsuite'
> make[2]: Leaving directory `/home/jakob/gdb7/gdb-host-revpatched/gdb'
> make[1]: Nothing to be done for `check-target'.
> make[1]: Leaving directory `/home/jakob/gdb7/gdb-host-revpatched'
> ---
>
> Which seems to indicate that no tests were actually run. This is a 6.8.50 branch
> that I checked out of cvs late last week.
>
> What is required to actually run the reverse tests? Do I need to build my gdb in
> any special way?
>
> I suspect that this line the test scripts is the cause of the premature exit
> from the tests:
>
> ---
> if ![target_info exists gdb,can_reverse] {
>    return
> }
> ---
>
> So how do I make gdb realize that it can indeed reverse itself?
>
> 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
> ________________________________________________________
>
>
>
>

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

[Jakob Engblom]

> 
> To use the testsuite of reverse:
> 
> cat /usr/share/dejagnu/baseboards/precord.exp
> # Testing programs using process record/replay (precord)
> load_base_board_description "unix"
> set_board_info gdb,can_reverse 1
> set_board_info gdb,use_precord 1

...

Your suggestion is to add an external dejagnu script, as I understand it?

Does this mean that we cannot run the reverse tests as part of the regular gdb
test suite? Do you need to put some special scaffold like this in place outside
of gdb to make this work?  That does not look very scalable to me? 

Anyway, it seems like if we can make our mi-reverse tests work with the same
precondition as the above, we should have something acceptable at least.

/jakob

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

[Jakob Engblom]

> make check RUNTESTFLAGS="break-reverse.exp --target_board=precord" &&

I had to do 

make check RUNTESTFLAGS="gdb.reverse/break-reverse.exp --target_board=precord"


To make this work, after creating the precord.exp file in
/usr/share/dejagnu/baseboards/

What do you need to do to run the test without prefixing all files with
"gdb.reverse/..."?  Is this just a small convenience in your setup, or something
more fundamental?


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
________________________________________________________
  

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

[Pedro Alves]

On Monday 17 August 2009 12:32:50, Jakob Engblom wrote:
> > make check RUNTESTFLAGS="break-reverse.exp --target_board=precord" &&
> 
> I had to do 
> 
> make check RUNTESTFLAGS="gdb.reverse/break-reverse.exp --target_board=precord"
> 
> 
> To make this work, after creating the precord.exp file in
> /usr/share/dejagnu/baseboards/
> 

You don't really need to clobber that directory.  

See:
http://sourceware.org/gdb/wiki/TestingGDB#head-4eade7db27381c0f4747113b6edea1b8f365d73f

# 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". 

Adjust as needed, of course.

Although, needing to set "gdb,use_precord" seems weird
though.  Can't we make it so that if we're testing a native
gdb, and, if the target matches a list of targets that support
precord, then, well, claim support for reverse, and test with precord?
That is, get rid of the  need for a board file at all unless testing
against a remote target that supports reverse.

In any case, for the cases a board file is needed for testing
reverse, it would be nice to have that explained in the
wiki (or somewhere else).

-- 
Pedro Alves

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

[Pedro Alves]

On Monday 17 August 2009 12:51:06, Pedro Alves wrote:
> In any case, for the cases a board file is needed for testing
> reverse, it would be nice to have that explained in the
> wiki (or somewhere else).

I should add that it is a shame that the remote targets
don't report support for reverse until GDB tries it first...

How bad is the failure mode in the reverse tests if the target
does not support reverse at all?  Can't we try a simple
probing-for-support reverse test and if that fails skip the
rest of the reverse tests?  That would likely get rid of all
the current needs for a hacked board file.

-- 
Pedro Alves

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

[Hui Zhu]

On Mon, Aug 17, 2009 at 19:55, Pedro Alves<pedro@codesourcery.com> wrote:
> On Monday 17 August 2009 12:51:06, Pedro Alves wrote:
>> In any case, for the cases a board file is needed for testing
>> reverse, it would be nice to have that explained in the
>> wiki (or somewhere else).
>
> I should add that it is a shame that the remote targets
> don't report support for reverse until GDB tries it first...
>
> How bad is the failure mode in the reverse tests if the target
> does not support reverse at all?  Can't we try a simple
> probing-for-support reverse test and if that fails skip the
> rest of the reverse tests?  That would likely get rid of all
> the current needs for a hacked board file.
>
> --
> Pedro Alves
>

It will be very helpful.

If the target don't support reverse,  it will out like:
(gdb) rc
Target child does not support this command.

Thanks,
Hui

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

[Michael Snyder]

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.

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
     }

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"
     }

You won't want to use those commands, so you will
not define that variable in your board description.

If there are any commands that are unique to your
implementation, you can define your own guard variable
and add them to the tests.

Thanks
Michael



Pedro Alves wrote:
> On Monday 17 August 2009 12:32:50, Jakob Engblom wrote:
>>> make check RUNTESTFLAGS="break-reverse.exp --target_board=precord" &&
>> I had to do 
>>
>> make check RUNTESTFLAGS="gdb.reverse/break-reverse.exp --target_board=precord"
>>
>>
>> To make this work, after creating the precord.exp file in
>> /usr/share/dejagnu/baseboards/
>>
> 
> You don't really need to clobber that directory.  
> 
> See:
> http://sourceware.org/gdb/wiki/TestingGDB#head-4eade7db27381c0f4747113b6edea1b8f365d73f
> 
> # 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". 
> 
> Adjust as needed, of course.
> 
> Although, needing to set "gdb,use_precord" seems weird
> though.  Can't we make it so that if we're testing a native
> gdb, and, if the target matches a list of targets that support
> precord, then, well, claim support for reverse, and test with precord?
> That is, get rid of the  need for a board file at all unless testing
> against a remote target that supports reverse.
> 
> In any case, for the cases a board file is needed for testing
> reverse, it would be nice to have that explained in the
> wiki (or somewhere else).
> 

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

[Jakob Engblom]

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

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

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

[Jakob Engblom]

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

Trying to scope out the patch we are soon to contribute for MI commands for
reverse.

/jakob

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

[Jakob Engblom]

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

OK. I had hoped to find some nice general subset that you could test on any
reversible platform.  Obviously, enabling reverse would differ between targets,
but once it is run running, the semantics have to be the same for the commands
which are common. 

Then the precord-specific commands can be tested in their own right, right?
 

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
________________________________________________________
  

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

[Jakob Engblom]

> > In any case, for the cases a board file is needed for testing
> > reverse, it would be nice to have that explained in the
> > wiki (or somewhere else).
> 
> I should add that it is a shame that the remote targets
> don't report support for reverse until GDB tries it first...
> 
> How bad is the failure mode in the reverse tests if the target
> does not support reverse at all?  Can't we try a simple
> probing-for-support reverse test and if that fails skip the
> rest of the reverse tests?  That would likely get rid of all
> the current needs for a hacked board file.

I think remote targets need to be able to report their features, including
reversible debug. 

/jakob

Simics & reverse execution

[Jakob Engblom]

In a thread about testing gdb reverse, Michael Snyder asked this question about
reverse debug and Simics:

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

I think it helps to explain how Simics does reverse execution (and which is
fairly similar if more nimble than the VMWare implementation currently). 

Essentially, reverse execution is implemented on the hardware level. Simics
simulates an entire system: core processors, their surrounding devices on a
typical system-on-chip, memories, disks, networks, PCI, RapidIO, etc.  In
extreme cases, we are talking about entire virtual networks and virtual SMP
servers with 10s, 100s, or 1000s of processors. 

The key level that Simics observes is the software interface to the hardware.
Simics does not need to know anything about the software to run it, it just
simulates the hardware. 

To reverse execution in Simics, you use a combination of record and reexecution
techniques. Simics itself is 100% repeatable in its execution, and it can record
any asynchronous user input to a system like network packets and users typing on
keyboards attached to virtual systems.  To reverse the execution, you jump back
to a checkpoint fo the system state and then you reexecute forward, to a place
before your current position in time.  There is a good illustration of this in
the white paper at
http://www.virtutech.com/whitepapers/simics_checkpointing.html . 

Doing reverse breakpoints basically involves successively jumping back and
executing forward until breakpoints trigger. I think process record does
something very similar, based on the recording, right?  

From the outside, the semantics are identical to process record -- except that
there is no recording. But you have a limited window in both cases to which you
can go back (you start reverse execution at some point in time, which could be
system boot, or some later point).  

When we mix in gdb reverse with this, it is just an interface to the Simics core
engine.  Gdb reverse can be attached at any point during a run. Often, the way
you do things is to boot a machine to prompt (or open the booted state from a
checkpoint stored on disk), load target software in some way, and turn on
reverse execution when things get interesting: such as setting up the
configuration for the software to run, starting dependent services, connecting
to network servers, etc. 

Once the program you want to debug runs, you open a gdb remote connection and
attach gdb. Note that Simics by default lets gdb remote control one processor at
the hardware level, which is useful for bare-hardware or kernel-level debug.  We
can also use OS awarenesss to have a remote gdb only debug a certain process
when it is running.   Note that the Simics reverse affects the entire software
stack, including any writes to memory, disk, network packets sent, and kernel
process schedulings and interrupts from hardware.  In many ways, this makes
implementing reverse execution easier: there is a single interface level to
attack, no need to udnerstand the operating system on the target. 

As far as gdb remote is concerned, you can conceptually reverse into a time
prior to when gdb remote was attached. The underlying "recording" has no
relation to the actions of gdb remote.  

In simics, there are additional controls than regular debugging, such as turning
off reverse execution during a simulation. And "clearing the recording",
essentially making the current point in time the start of an unknown future
where asynchronous input from the user and environment is allowed, and the
system will take a different path than it took previously.  This does not
necessarily need to be addressed over gdb-remote.  But it might map to some of
the process record commands quite naturally.

What this means for Simics and gdb remote is that it would be nice to be able to
deal with points in time: in Simics, you are moving the target system clock
around in time arbitrarily.  In the Simics reverse interface, you can go to a
certain point in time, and also set execution bookmarks. 

But from a gdb perspective, all of this is hidden in a remote black box that
talks gdb remote. 

/jakob

Re: Simics & reverse execution

[Hui Zhu]

This is really a big mail.  And looks like a AD.  :)

I think you mean is simics can support reverse with remote like vmware, right?

Hui

On Wed, Aug 19, 2009 at 15:33, Jakob Engblom <jakob@virtutech.com> wrote:
>
> In a thread about testing gdb reverse, Michael Snyder asked this question about
> reverse debug and Simics:
>
> > 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?
>
> I think it helps to explain how Simics does reverse execution (and which is
> fairly similar if more nimble than the VMWare implementation currently).
>
> Essentially, reverse execution is implemented on the hardware level. Simics
> simulates an entire system: core processors, their surrounding devices on a
> typical system-on-chip, memories, disks, networks, PCI, RapidIO, etc.  In
> extreme cases, we are talking about entire virtual networks and virtual SMP
> servers with 10s, 100s, or 1000s of processors.
>
> The key level that Simics observes is the software interface to the hardware.
> Simics does not need to know anything about the software to run it, it just
> simulates the hardware.
>
> To reverse execution in Simics, you use a combination of record and reexecution
> techniques. Simics itself is 100% repeatable in its execution, and it can record
> any asynchronous user input to a system like network packets and users typing on
> keyboards attached to virtual systems.  To reverse the execution, you jump back
> to a checkpoint fo the system state and then you reexecute forward, to a place
> before your current position in time.  There is a good illustration of this in
> the white paper at
> http://www.virtutech.com/whitepapers/simics_checkpointing.html .
>
> Doing reverse breakpoints basically involves successively jumping back and
> executing forward until breakpoints trigger. I think process record does
> something very similar, based on the recording, right?
>
> From the outside, the semantics are identical to process record -- except that
> there is no recording. But you have a limited window in both cases to which you
> can go back (you start reverse execution at some point in time, which could be
> system boot, or some later point).
>
> When we mix in gdb reverse with this, it is just an interface to the Simics core
> engine.  Gdb reverse can be attached at any point during a run. Often, the way
> you do things is to boot a machine to prompt (or open the booted state from a
> checkpoint stored on disk), load target software in some way, and turn on
> reverse execution when things get interesting: such as setting up the
> configuration for the software to run, starting dependent services, connecting
> to network servers, etc.
>
> Once the program you want to debug runs, you open a gdb remote connection and
> attach gdb. Note that Simics by default lets gdb remote control one processor at
> the hardware level, which is useful for bare-hardware or kernel-level debug.  We
> can also use OS awarenesss to have a remote gdb only debug a certain process
> when it is running.   Note that the Simics reverse affects the entire software
> stack, including any writes to memory, disk, network packets sent, and kernel
> process schedulings and interrupts from hardware.  In many ways, this makes
> implementing reverse execution easier: there is a single interface level to
> attack, no need to udnerstand the operating system on the target.
>
> As far as gdb remote is concerned, you can conceptually reverse into a time
> prior to when gdb remote was attached. The underlying "recording" has no
> relation to the actions of gdb remote.
>
> In simics, there are additional controls than regular debugging, such as turning
> off reverse execution during a simulation. And "clearing the recording",
> essentially making the current point in time the start of an unknown future
> where asynchronous input from the user and environment is allowed, and the
> system will take a different path than it took previously.  This does not
> necessarily need to be addressed over gdb-remote.  But it might map to some of
> the process record commands quite naturally.
>
> What this means for Simics and gdb remote is that it would be nice to be able to
> deal with points in time: in Simics, you are moving the target system clock
> around in time arbitrarily.  In the Simics reverse interface, you can go to a
> certain point in time, and also set execution bookmarks.
>
> But from a gdb perspective, all of this is hidden in a remote black box that
> talks gdb remote.
>
> /jakob
>

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

[Pedro Alves]

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

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

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

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

Pedro>  1. for native targets, the only reverse solution we currently support is
Pedro>  precord.  I can't see why we can't default to testing the reverse tests
Pedro>  with precord then.

I agree.

If the tests aren't enabled by default on some common platforms and thus
run as a regular part of testing, you can be sure there will be
regressions here.

Tom

RE: Simics & reverse execution

[Jakob Engblom]

> This is really a big mail.  And looks like a AD.  :)
> 
> I think you mean is simics can support reverse with remote like vmware, right?

I think the answer is that method used seems mostly the same.  

The key thing for me was to explain that the time scope of the reversible run is
potentially larger than what any particular gdb-remote connection sees: i.e., it
is nice if gdb would accept backing into "before it was attached" logically, and
not assume too much control over the reversing in itself. 

And that a probe for reversibility in gbd-remote would be a worthwhile addition
to the protocol. 

/jakob
 
> Hui
> 
> On Wed, Aug 19, 2009 at 15:33, Jakob Engblom <jakob@virtutech.com> wrote:
> >
> > In a thread about testing gdb reverse, Michael Snyder asked this question
about
> > reverse debug and Simics:
> >
> > > 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?
> >
> > I think it helps to explain how Simics does reverse execution (and which is
> > fairly similar if more nimble than the VMWare implementation currently).
> >
> > Essentially, reverse execution is implemented on the hardware level. Simics
> > simulates an entire system: core processors, their surrounding devices on a
> > typical system-on-chip, memories, disks, networks, PCI, RapidIO, etc.  In
> > extreme cases, we are talking about entire virtual networks and virtual SMP
> > servers with 10s, 100s, or 1000s of processors.
> >
> > The key level that Simics observes is the software interface to the
hardware.
> > Simics does not need to know anything about the software to run it, it just
> > simulates the hardware.
> >
> > To reverse execution in Simics, you use a combination of record and
reexecution
> > techniques. Simics itself is 100% repeatable in its execution, and it can
> record
> > any asynchronous user input to a system like network packets and users
typing
> on
> > keyboards attached to virtual systems.  To reverse the execution, you jump
back
> > to a checkpoint fo the system state and then you reexecute forward, to a
place
> > before your current position in time.  There is a good illustration of this
in
> > the white paper at
> > http://www.virtutech.com/whitepapers/simics_checkpointing.html .
> >
> > Doing reverse breakpoints basically involves successively jumping back and
> > executing forward until breakpoints trigger. I think process record does
> > something very similar, based on the recording, right?
> >
> > From the outside, the semantics are identical to process record -- except
that
> > there is no recording. But you have a limited window in both cases to which
you
> > can go back (you start reverse execution at some point in time, which could
be
> > system boot, or some later point).
> >
> > When we mix in gdb reverse with this, it is just an interface to the Simics
> core
> > engine.  Gdb reverse can be attached at any point during a run. Often, the
way
> > you do things is to boot a machine to prompt (or open the booted state from
a
> > checkpoint stored on disk), load target software in some way, and turn on
> > reverse execution when things get interesting: such as setting up the
> > configuration for the software to run, starting dependent services,
connecting
> > to network servers, etc.
> >
> > Once the program you want to debug runs, you open a gdb remote connection
and
> > attach gdb. Note that Simics by default lets gdb remote control one
processor
> at
> > the hardware level, which is useful for bare-hardware or kernel-level debug.
>  We
> > can also use OS awarenesss to have a remote gdb only debug a certain process
> > when it is running.   Note that the Simics reverse affects the entire
software
> > stack, including any writes to memory, disk, network packets sent, and
kernel
> > process schedulings and interrupts from hardware.  In many ways, this makes
> > implementing reverse execution easier: there is a single interface level to
> > attack, no need to udnerstand the operating system on the target.
> >
> > As far as gdb remote is concerned, you can conceptually reverse into a time
> > prior to when gdb remote was attached. The underlying "recording" has no
> > relation to the actions of gdb remote.
> >
> > In simics, there are additional controls than regular debugging, such as
> turning
> > off reverse execution during a simulation. And "clearing the recording",
> > essentially making the current point in time the start of an unknown future
> > where asynchronous input from the user and environment is allowed, and the
> > system will take a different path than it took previously.  This does not
> > necessarily need to be addressed over gdb-remote.  But it might map to some
of
> > the process record commands quite naturally.
> >
> > What this means for Simics and gdb remote is that it would be nice to be
able
> to
> > deal with points in time: in Simics, you are moving the target system clock
> > around in time arbitrarily.  In the Simics reverse interface, you can go to
a
> > certain point in time, and also set execution bookmarks.
> >
> > But from a gdb perspective, all of this is hidden in a remote black box that
> > talks gdb remote.
> >
> > /jakob
> >

Re: Simics & reverse execution

[Michael Snyder]

Jakob Engblom wrote:

> The key thing for me was to explain that the time scope of the reversible run is
> potentially larger than what any particular gdb-remote connection sees: i.e., it
> is nice if gdb would accept backing into "before it was attached" logically, and
> not assume too much control over the reversing in itself. 

If I understand you correctly, I think there's no problem.

You want to be able to reverse-continue to a point in the execution 
history that is earlier than when gdb attached -- right?

Should be ok -- gdb doesn't really 'know' anything special
about the point in "time" when it attached.

> And that a probe for reversibility in gbd-remote would be a worthwhile addition
> to the protocol. 

Sounds like a good idea.  Maybe a 'q' query?
"qReverse", maybe?

Re: Simics & reverse execution

[Daniel Jacobowitz]

On Wed, Aug 19, 2009 at 12:59:19PM -0700, Michael Snyder wrote:
> >And that a probe for reversibility in gbd-remote would be a worthwhile addition
> >to the protocol.
> 
> Sounds like a good idea.  Maybe a 'q' query?
> "qReverse", maybe?

Just use qSupported?

(I feel like we've discussed this before... :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: Simics & reverse execution

[Pedro Alves]

On Wednesday 19 August 2009 20:59:19, Michael Snyder wrote:
> Sounds like a good idea.  Maybe a 'q' query?
> "qReverse", maybe?

Why not use the standard qSupported mechanism?  I think
we've been over this before.  :-)

-- 
Pedro Alves

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

[Hui Zhu]

On Wed, Aug 19, 2009 at 20:28, Pedro Alves<pedro@codesourcery.com> wrote:
> 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".
>

I think it's very useful.  Thanks.

Hui

RE: Simics & reverse execution

[Jakob Engblom]

> > Sounds like a good idea.  Maybe a 'q' query?
> > "qReverse", maybe?
> 
> Why not use the standard qSupported mechanism?  I think
> we've been over this before.  :-)

You are the experts on this. Tell us what the query is and we will implement it.


I was mostly concerned with any ill effects of reversing to before gdb started.
Looks like the state maintained is sufficiently time-independent that that is
not a problem.

I have no insight into the gdb roadmap, but wasn't there a discussion on adding
time and bookmarks in the execution at some point?  That would be very
worthwhile as an addition, I think.

/jakob

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

[Jakob Engblom]

> Pedro> For the generic reverse execution tests --- reverse step, reverse
> Pedro> next, reverse continue, run to breakpoint in reverse, etc., etc.,
> Pedro> I'd must prefer that we would get rid of the need for board files
> Pedro> at all.  :-)
> 
> Pedro>  1. for native targets, the only reverse solution we currently support
is
> Pedro>  precord.  I can't see why we can't default to testing the reverse
tests
> Pedro>  with precord then.
> 
> I agree.
> 
> If the tests aren't enabled by default on some common platforms and thus
> run as a regular part of testing, you can be sure there will be
> regressions here.

So the question here is: who will deal with removing the board file dependency?
I don't think we and our consultants doing the work for us are competent
enough...

So is it OK if we submit a kit of tests which are structured in the same way as
the current reverse tests? Then we can deal with upgrading the tests later, once
the board file requirements has been fixed?


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
________________________________________________________
  

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

[Daniel Jacobowitz]

On Thu, Aug 20, 2009 at 08:54:31AM +0200, Jakob Engblom wrote:
> So is it OK if we submit a kit of tests which are structured in the same way as
> the current reverse tests? Then we can deal with upgrading the tests later, once
> the board file requirements has been fixed?

Yes, I think that's a good general rule - this problem won't get any
harder by the addition of another test.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Simics & reverse execution

[Pedro Alves]

On Thursday 20 August 2009 07:54:31, Jakob Engblom wrote:
> > > Sounds like a good idea.  Maybe a 'q' query?
> > > "qReverse", maybe?
> > 
> > Why not use the standard qSupported mechanism?  I think
> > we've been over this before.  :-)
> 
> You are the experts on this. Tell us what the query is and we will implement it.

It's not complicated: GDB's first packet to a remote stub is "qSupported".  The
target replies back a list of supported features.   We just need support in
GDB for a new "reverse" feature.  See:
http://sourceware.org/gdb/current/onlinedocs/gdb_34.html#qSupported

In gdb/remote.c, you can get a feeling for what you'd need by e.g., 
looking at remote_protocol_features, and at the "multiprocess" feature
handling.  Then, remote.c:remote_can_reverse can be tweaked to inform
the rest of GDB that the remote end supports reversing or not,
instead of the current hardcoded "yes".

Then, you could even hook this to MI's "-list-target-features", so
that a frontend can know upfront if it is connected to a target
that supports reverse or not, so that e.g., it can enable or
disable UI features/widgets/whatnot related to reverse
debugging support.

-- 
Pedro Alves

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

[Pedro Alves]

On Monday 17 August 2009 16:31:19, Hui Zhu wrote:
> > How bad is the failure mode in the reverse tests if the target
> > does not support reverse at all?  Can't we try a simple
> > probing-for-support reverse test and if that fails skip the
> > rest of the reverse tests?  That would likely get rid of all
> > the current needs for a hacked board file.
> >
> > --
> > Pedro Alves
> >
> 
> It will be very helpful.
> 
> If the target don't support reverse,  it will out like:
> (gdb) rc
> Target child does not support this command.

That's a native target ("child").  I don't think you'll get that
error currently against *remote* targets.  Looking at remote.c:remote_resume,
I think a reverse-continue command against gdbserver will
end up sending a regular forward-direction "vCont" packet, so the
remote inferior will execute *forward* instead of reverse... 

Oh well, it's easy to try.  Here it goes:

 $./gdbserver :9999 ./gdbserver
 ./gdb ./gdbserver/gdbserver
 (gdb) tar remote :9999
 (gdb) b main
 (gdb) c
 1884      char **next_arg = &argv[1];
 (gdb) reverse-step
 1885      int multi_mode = 0;

If you disable the vCont packet, with "set remote verbose-resume-packet off",
then GDB will indeed send the correct back-step or back-continue
("bs"/"bc") packets, but, those will be ignored by gdbserver...  You'll end
up with a broken debug session if you try this:

 1884      char **next_arg = &argv[1];
 (gdb) set remote verbose-resume-packet off
 (gdb) reverse-step
 warning: Invalid remote reply:
 <gdb hangs>
 <ctrl-c>
 <ctrl-c>
 Interrupted while waiting for the program.
 Give up (and stop debugging it)? (y or n)

...

It's really much better if the target reports
support or not upfront, so that GDB doesn't even *try* anything
reverse if the target does not support it.

-- 
Pedro Alves

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

[Michael Snyder]

Jakob Engblom wrote:
>> Pedro> For the generic reverse execution tests --- reverse step, reverse
>> Pedro> next, reverse continue, run to breakpoint in reverse, etc., etc.,
>> Pedro> I'd must prefer that we would get rid of the need for board files
>> Pedro> at all.  :-)
>>
>> Pedro>  1. for native targets, the only reverse solution we currently support
> is
>> Pedro>  precord.  I can't see why we can't default to testing the reverse
> tests
>> Pedro>  with precord then.
>>
>> I agree.
>>
>> If the tests aren't enabled by default on some common platforms and thus
>> run as a regular part of testing, you can be sure there will be
>> regressions here.
> 
> So the question here is: who will deal with removing the board file dependency?
> I don't think we and our consultants doing the work for us are competent
> enough...
> 
> So is it OK if we submit a kit of tests which are structured in the same way as
> the current reverse tests? Then we can deal with upgrading the tests later, once
> the board file requirements has been fixed?

I think that would be great.

Re: Simics & reverse execution

[Michael Snyder]

Jakob Engblom wrote:

> Doing reverse breakpoints basically involves successively jumping back and
> executing forward until breakpoints trigger. I think process record does
> something very similar, based on the recording, right?

No, that's one major difference with process-record.
It doesn't use any state snapshots or checkpoints, its data contains
only change sets for single instructions.  So it executes backward
one instruction at a time, in reverse sequence.

Of course, to the user, and to the core of gdb, the difference
is invisible, except possibly for speed.

[...]
> What this means for Simics and gdb remote is that it would be nice to be able to
> deal with points in time: in Simics, you are moving the target system clock
> around in time arbitrarily.  In the Simics reverse interface, you can go to a
> certain point in time, and also set execution bookmarks. 

Those are both very cool ideas, and I would like to add them,
both to the remote protocol and to process remote.

I think we just need to come up with a sufficiently arbitrary
way to represent both a "point in time" and a "bookmark", so
that they can be passed back and forth between gdb and the
remote target without gdb needing to know what they actually
represent (eg. a timestamp or a branch count).  Only the target
needs to know how to interpret them.

Maybe an 8 byte integer would be sufficient?  What do you think?

So I'm thinking something like:
1) user to gdb: "I want to place a bookmark here (now)".
2) gdb to target: "Give me a marker that I can later use to mean "here 
(now)".
3) target to gdb: "Ok, here, use this instruction count."
4) (later): user to gdb: "I want to return to this bookmark".
5) gdb to target: "Please return to this marker that you gave me earlier".

RE: Simics & reverse execution

[Jakob Engblom]

> I think we just need to come up with a sufficiently arbitrary
> way to represent both a "point in time" and a "bookmark", so
> that they can be passed back and forth between gdb and the
> remote target without gdb needing to know what they actually
> represent (eg. a timestamp or a branch count).  Only the target
> needs to know how to interpret them.
> 
> Maybe an 8 byte integer would be sufficient?  What do you think?

I think a logical clock is the only sensible solution, actually, as you say, we
cannot know the time. In Simics, we use cycle counts, and bookmarks are just
names for a particular cycle count point.  A good question is whether bookmarks
should be part of state in gdb or in the backend or both.

Obviously, there are nasty corner cases that are too complex for this protocol
to handle.  In particular, if you are using a temporally decoupled simulation
engine where multiple processors are run for time slices before switching to the
next, there is a minor chance that you can see time jump back and forth (local
time on th current processor) as you execute logically forward... our tools
handle that, but it is pretty hard to do right and I don't expect gdb to have to
deal with that. Let the backends do it.

/jakob

Re: Simics & reverse execution

[Michael Snyder]

Jakob Engblom wrote:
>> I think we just need to come up with a sufficiently arbitrary
>> way to represent both a "point in time" and a "bookmark", so
>> that they can be passed back and forth between gdb and the
>> remote target without gdb needing to know what they actually
>> represent (eg. a timestamp or a branch count).  Only the target
>> needs to know how to interpret them.
>>
>> Maybe an 8 byte integer would be sufficient?  What do you think?
> 
> I think a logical clock is the only sensible solution, actually, as you say, we
> cannot know the time. In Simics, we use cycle counts, and bookmarks are just
> names for a particular cycle count point.  A good question is whether bookmarks
> should be part of state in gdb or in the backend or both.
> 
> Obviously, there are nasty corner cases that are too complex for this protocol
> to handle.  In particular, if you are using a temporally decoupled simulation
> engine where multiple processors are run for time slices before switching to the
> next, there is a minor chance that you can see time jump back and forth (local
> time on th current processor) as you execute logically forward... our tools
> handle that, but it is pretty hard to do right and I don't expect gdb to have to
> deal with that. Let the backends do it.

I think we're saying the same thing.  GDB doesn't know anything about
logical clocks.  The target (simics/process record/vmware/whoever) can
give gdb an arbitrary piece of data to represent a bookmark, and gdb can
give it back again later.  For Simics, it may be a timestamp or logical
clock.  For process record, I think it would be an instruction count.
GDB should not care what it is.

We just need to decide on a data protocol representation for it.

For a UI, we just need to present a list to the user, something like
we do for breakpoints.  Each bookmark (checkpoint?) can be identified
by a small counting integer, and then maybe some target-specific
description such as we do for threads (where the target has a callback
for presenting "thread info" in a user-readable way).

Re: Simics & reverse execution

[Greg Law]

Hi,

Michael Snyder wrote:
 > [...]
 >
 > I think we just need to come up with a sufficiently arbitrary
 > way to represent both a "point in time" and a "bookmark", so
 > that they can be passed back and forth between gdb and the
 > remote target without gdb needing to know what they actually
 > represent (eg. a timestamp or a branch count).  Only the target
 > needs to know how to interpret them.
 >
 > Maybe an 8 byte integer would be sufficient?  What do you think?

As you know, we're currently putting together a remote target so that 
UndoDB can take advantage of gdb's new reverse debug support.  (We hope 
to have something ready quite soon.)

Anyway, 8-bytes is not a sufficiently general representation of time for 
UndoDB. The trouble is, we don't keep a linear cycle count or such like. 
  We could in theory, but it would slow us down.  So instead we 
represent time as a structure.

So, I think it would be better if the abstract time representation could 
be an opaque "bag of bits" of arbitrary size.

We'd be happy to contribute some patches along these lines, although I 
don't think we'd be able to do anything in time for the proposed gdb 7 
branch.

What do people think?

Cheers,

Greg

-- 
Greg Law, Undo Software                       http://undo-software.com/

RE: Simics & reverse execution

[Jakob Engblom]

> Anyway, 8-bytes is not a sufficiently general representation of time for
> UndoDB. The trouble is, we don't keep a linear cycle count or such like.
>   We could in theory, but it would slow us down.  So instead we
> represent time as a structure.

What exactly is represented here? Some kind of tree of execution?

If it is a linear execution, couldn't you just map arbitrary points in time to
integers?

Also, note that as Michael says, the idea here is to have an ID number that
passes back and forth between gdb and the target, which is then resolved at the
target. 
 
> So, I think it would be better if the abstract time representation could
> be an opaque "bag of bits" of arbitrary size.
> 
> We'd be happy to contribute some patches along these lines, although I
> don't think we'd be able to do anything in time for the proposed gdb 7
> branch.
> 
> What do people think?

I think it might be unnecessary: unless you need more than 2^64 distinct
bookmarks/points in time tracked, can't you do a local map in your backend
between gdb logical bookmark IDs and the internal time representation?

Note in that in our case, the "time" is not really that simple... when you
factor in multithreaded simulation of multiboard targets and temporal
decoupling, Simics typically has ten different "points in time" active at the
same time... but for reveexec, we untangle this for the benefit of the user. 

/jakob

Re: Simics & reverse execution

[Greg Law]

Jakob Engblom wrote:
>> Anyway, 8-bytes is not a sufficiently general representation of time for
>> UndoDB. The trouble is, we don't keep a linear cycle count or such like.
>>   We could in theory, but it would slow us down.  So instead we
>> represent time as a structure.
> 
> What exactly is represented here? Some kind of tree of execution?

No, it's essentially a combination of pointers that we know will 
uniquely identify a point in history.

> 
> If it is a linear execution, couldn't you just map arbitrary points in time to
> integers?
> 
> Also, note that as Michael says, the idea here is to have an ID number that
> passes back and forth between gdb and the target, which is then resolved at the
> target. 
>  
>> So, I think it would be better if the abstract time representation could
>> be an opaque "bag of bits" of arbitrary size.
>>
>> We'd be happy to contribute some patches along these lines, although I
>> don't think we'd be able to do anything in time for the proposed gdb 7
>> branch.
>>
>> What do people think?
> 
> I think it might be unnecessary: unless you need more than 2^64 distinct
> bookmarks/points in time tracked, can't you do a local map in your backend
> between gdb logical bookmark IDs and the internal time representation?
> 
> Note in that in our case, the "time" is not really that simple... when you
> factor in multithreaded simulation of multiboard targets and temporal
> decoupling, Simics typically has ten different "points in time" active at the
> same time... but for reveexec, we untangle this for the benefit of the user. 

I guess my worry is that there would be some kind of ordering associated 
with the time values.

That is, we could use such a mapping, as long as no one assumes that you 
can do an integer compare of two bookmarks or times to know whether one 
is "later" than the other.

If the 64 bits of the integer were to be considered 'opaque' and no more 
than a unique handle onto a point in history, that would be fine.  But 
such a restriction is unfortunate, because you wouldn't be able to e.g. 
binary chop history.

Obviously, any opaque bag of bits is going to suffer like that.  What we 
do currently in UndoDB is to have calls to get a relatively course grain 
linear, scalar integer value from an undodb_time_t.  It's coarse-grained 
in that several close together but distinct points in history (e.g. 
adjacent instructions) may get the same scalar value, but in reality not 
many, and so it's enough to do binary chops, etc.

Greg
-- 
Greg Law, Undo Software                       http://undo-software.com/

RE: Simics & reverse execution

[Jakob Engblom]

> If the 64 bits of the integer were to be considered 'opaque' and no more
> than a unique handle onto a point in history, that would be fine.  But
> such a restriction is unfortunate, because you wouldn't be able to e.g.
> binary chop history.

But on which side of the debugger connection would you do this?

This can work eminently with opaque IDs: just have your scripted backend setup
the binary search or whatever, telling gdb that new bookmarks have appeared as
it runs. 

Actually, I think an important feature here would be to push bookmarks from the
backend to the gdb. So that the backend can provide useful insights to gdb.
This also lets the backend in some ways hook debug events that gdb has no idea
about, such as interrupts, hardware accesses, hypervisor activity that switches
around operating systems, and other things. 

/jakob

Re: Simics & reverse execution

[Greg Law]

Jakob Engblom wrote:
>> If the 64 bits of the integer were to be considered 'opaque' and no more
>> than a unique handle onto a point in history, that would be fine.  But
>> such a restriction is unfortunate, because you wouldn't be able to e.g.
>> binary chop history.
> 
> But on which side of the debugger connection would you do this?

I was assuming it would be driven by the gdb side.  One can imagine 
"smart" targets that allow optimized binary chop type stuff.  But it 
seems reasonable to assume that not all targets will have such smarts.

Most important I think is to enable the user to do the binary chop.  It 
might not be a straight-forward thing they're looking for, and in 
general it would be a very useful thing for the user to be able to say, 
essentially, "back a bit, back a bit more, forward a bit".

For that to work we need some way for gdb to know about and be able to 
control a point in history relative to other points in history.

As I mentioned earlier, a way to convert between an opaque handle and a 
scalar value would allow this (this is what UndoDB does right now).  An 
alternative take would be to enable gdb to query and set the percentage 
through recorded history we are right now.  That is, use two interfaces: 
one to get/set an opaque, unique timestamp ID (used for bookmarks) and 
another to get/set the percentage of the way through the record log we 
currently are (to allow e.g. a graphical frontend to implement a 
slide-bar to show where in the record log we are).  The former is 
precise to instruction count (and signals, etc); the latter may not be 
depending on the details of the target.  Actually, percentage is the 
wrong term -- better would be what fraction of the way are we through 
history, e.g. in 1/(2^64) increments, such that half way through 
recorded history would be represented as 2^63.

I don't have strong opinions on exactly how the protocol should express 
this.  But I do think we need a "precise" notion of time (e.g. for 
bookmarks) and a "relative" notion of time (e.g. for displaying a 
slide-bar in a GUI).  If we're to use the same "type" to do both jobs, 
an 8-byte integer is a bit restrictive.  If we're to use different types 
(probably with conversion between the two), then each being an 8-byte 
integer is fine.


Greg
-- 
Greg Law, Undo Software                       http://undo-software.com/

RE: Simics & reverse execution

[Jakob Engblom]

> currently are (to allow e.g. a graphical frontend to implement a
> slide-bar to show where in the record log we are).  The former is
> precise to instruction count (and signals, etc); the latter may not be
> depending on the details of the target.  Actually, percentage is the
> wrong term -- better would be what fraction of the way are we through
> history, e.g. in 1/(2^64) increments, such that half way through
> recorded history would be represented as 2^63.

I can see one big problem with this: you are assuming a bounded recording. 

In our case, it is unbounded (except for the current 64 bit counter of
picoseconds used to coordinate all processors and other time-dependent parts in
a simulation system, which bounds execution at an annoying 280 days of time).
In Simics, you can always just continue past the end of the previously seen
execution, and you extend the size of the reversible window.  I believe VMWare
does the same from my experiemtns with Workstation 6.5. 

I honestly think binary chop is best put into the backend for this reason... the
times I have seen it applied it relied on large state-checking scripts running
that had far better insight into the target system than you get with gdb (such
as doing global consistency checks on the state of file systems on various
boards in a fault-tolerant redundant cluster). 

/jakob

Re: Simics & reverse execution

[Greg Law]

Jakob Engblom wrote:
>> currently are (to allow e.g. a graphical frontend to implement a
>> slide-bar to show where in the record log we are).  The former is
>> precise to instruction count (and signals, etc); the latter may not be
>> depending on the details of the target.  Actually, percentage is the
>> wrong term -- better would be what fraction of the way are we through
>> history, e.g. in 1/(2^64) increments, such that half way through
>> recorded history would be represented as 2^63.
> 
> I can see one big problem with this: you are assuming a bounded recording. 

No.  Or at least, not consciously :)

In the notion above, we're talking about 1/(2^64) of however much log 
happens to have been recorded.  So yes, if you did a binary chop, then 
ran a bit in record mode to "grow" the log, and then did another binary 
chop, how much time 1/(2^64) of the log represents would change.  But 
that's what bookmarks are for -- these would give you a consistent 
marker to allow you to jump back and forth as the log grows (or even 
shrinks).

But I'm not wedded in any way to the above scheme.  Having some way to 
convert from an 8-byte 'precise' bookmark to an 8-byte 'imprecise' 
scalar representation would also be fine.  In the case of Simics it 
sounds like such an operation would be a no-op (both bookmarks and 
scalar values would be 8-byte picoseconds).

> 
> In our case, it is unbounded (except for the current 64 bit counter of
> picoseconds used to coordinate all processors and other time-dependent parts in
> a simulation system, which bounds execution at an annoying 280 days of time).

UndoDB is essentially the same (except our limits take us to about 30 
years :)

> In Simics, you can always just continue past the end of the previously seen
> execution, and you extend the size of the reversible window.  I believe VMWare
> does the same from my experiemtns with Workstation 6.5. 

Right, same for us.

> 
> I honestly think binary chop is best put into the backend for this reason... the
> times I have seen it applied it relied on large state-checking scripts running
> that had far better insight into the target system than you get with gdb (such
> as doing global consistency checks on the state of file systems on various
> boards in a fault-tolerant redundant cluster). 

Oh, I agree that binary chop intelligence in the back end could be a 
good thing.  It would be really nice one day to be able to have gdb say 
to the back end "find me the most recent time this arbitrary condition 
held".  However, that's quite complicated, and it seems reasonable to 
assume is a little way into the future.  More importantly, even when gdb 
supports it, it's likely that not _all_ back-ends would.  And more 
relevant still, whatever binary chop interface were defined, it seems 
that in addition it would be useful to export to the user the ability to 
jump to an arbitrary point in time, without necessarily having a 
bookmark there.  Talking purely in terms of binary chop is too limited. 
  Example - say the user wants to go back to the beginning of time, but 
didn't think to take a bookmark when they were there.  Executing 
backwards might take a long time.  For systems like Simics, UndoDB and 
VMware that use a snapshot-and-replay technique it can be almost instant 
to jump back to time 0.  We could always add a special command to goto 
time 0 or a special bookmark, but why not generalise it?  e.g. maybe the 
user wants to skip forwards a few seconds' worth, but again, doesn't 
have a bookmark conveniently placed.

It seems that for at least some targets this would be pretty 
straightforward to implement and a very useful feature for users.


Cheers,

Greg
-- 
Greg Law, Undo Software                       http://undo-software.com/

RE: Simics & reverse execution

[Jakob Engblom]

>   Example - say the user wants to go back to the beginning of time, but
> didn't think to take a bookmark when they were there.  Executing
> backwards might take a long time.  For systems like Simics, UndoDB and
> VMware that use a snapshot-and-replay technique it can be almost instant
> to jump back to time 0.  We could always add a special command to goto
> time 0 or a special bookmark, but why not generalise it?  e.g. maybe the
> user wants to skip forwards a few seconds' worth, but again, doesn't
> have a bookmark conveniently placed.
> 
> It seems that for at least some targets this would be pretty
> straightforward to implement and a very useful feature for users.

I agree with this, and I think that a notion of scalar time in some undefined
unit would make the UI on the gdb side much easier. Problem is that gdb
currently lacks a time concept... and my understanding is that introducing it is
going to be painful.  Time really becomes very pervasive once you start using it
in one place... 

So, currently, a bookmarks mechanism seems to make the most sense. I think that
most of the issues we have can be solved at the user-level:

* Always take a bookmark when you start (which normally for is not time zero,
but rather some arbitrary point in time of the target system when the reverse is
turned on). 

* Allows the backend to push bookmarks. In that way, you just set up a script or
module that sends bookmarks to gdb at a regular pace in target time (say every 1
microsecond on the target side or whatever). 

* Your frontend scripts can then rely on these bookmarks. 

Not super-solid, but it works with a simple bookmark mechanism and keeps time
internal to the backend.

/jakob

Re: Simics & reverse execution

[Greg Law]

On 09/07/2009 08:16 AM, Jakob Engblom wrote:
>
>>    Example - say the user wants to go back to the beginning of time, but
>> didn't think to take a bookmark when they were there.  Executing
>> backwards might take a long time.  For systems like Simics, UndoDB and
>> VMware that use a snapshot-and-replay technique it can be almost instant
>> to jump back to time 0.  We could always add a special command to goto
>> time 0 or a special bookmark, but why not generalise it?  e.g. maybe the
>> user wants to skip forwards a few seconds' worth, but again, doesn't
>> have a bookmark conveniently placed.
>>
>> It seems that for at least some targets this would be pretty
>> straightforward to implement and a very useful feature for users.
>
> I agree with this, and I think that a notion of scalar time in some undefined
> unit would make the UI on the gdb side much easier. Problem is that gdb
> currently lacks a time concept... and my understanding is that introducing it is
> going to be painful.  Time really becomes very pervasive once you start using it
> in one place...

Intriguing.  In what ways?

We currently have a somewhat baroque bunch of python that wraps up gdb 
to enable our reverse debugging commands on users system where they've 
an older version of gdb installed.  This includes some commands to 
display the current time and jump to an arbitrary time (where time is a 
scalar 64-bit integer).  The rest of gdb remains blissfully unaware 
(obviously, since it's unpatched).

I can see how in general "teaching" the concept of time to gdb would be 
a huge job.  But I don't think a command to jump around arbitrarily and 
another to display the "current" time needs to teach anything about time 
to the rest of gdb.


>
> So, currently, a bookmarks mechanism seems to make the most sense. I think that
> most of the issues we have can be solved at the user-level:
>
> * Always take a bookmark when you start (which normally for is not time zero,
> but rather some arbitrary point in time of the target system when the reverse is
> turned on).
>
> * Allows the backend to push bookmarks. In that way, you just set up a script or
> module that sends bookmarks to gdb at a regular pace in target time (say every 1
> microsecond on the target side or whatever).
>
> * Your frontend scripts can then rely on these bookmarks.
>
> Not super-solid, but it works with a simple bookmark mechanism and keeps time
> internal to the backend.

All of the above sounds good to me.

However, I still reckon a pair or commands simply to get and set the 
time as a scalar value should be both useful for the user, and  trivial 
to implement (he said, confidently :-)  It could be orthogonal to 
bookmarks (a way to convert bookmarks to scalar time value would be 
useful, but not essential to start with).

We should probably pipe up with some patches, but I'm just slightly 
nervous that I may have missed something, especially as I'm not really 
terribly au fait with gdb's internals and its assumptions (hence the 
discussion first).


Cheers,

Greg

-- 
Greg Law, Undo Software                       http://undo-software.com/

RE: Simics & reverse execution

[Jakob Engblom]

> > going to be painful.  Time really becomes very pervasive once you start
using
> it
> > in one place...
> 
> Intriguing.  In what ways?
> 
> We currently have a somewhat baroque bunch of python that wraps up gdb
> to enable our reverse debugging commands on users system where they've
> an older version of gdb installed.  This includes some commands to
> display the current time and jump to an arbitrary time (where time is a
> scalar 64-bit integer).  The rest of gdb remains blissfully unaware
> (obviously, since it's unpatched).
> 
> I can see how in general "teaching" the concept of time to gdb would be
> a huge job.  But I don't think a command to jump around arbitrarily and
> another to display the "current" time needs to teach anything about time
> to the rest of gdb.

Think about the cross-product with thread handling.  If you use time there, you
need to determine how to handle times for threads. One timeline per thread? Or a
global system time? 

You also really like to have time breakpoints in the system, to allow you to do
things like "run this system for 6.132 seconds and then stop" (typical operation
we do when skipping a boot sequence or we have run a workload several times and
know when itneresting things should start to happen). 
 
Also, how should this interact with non-stop debug? And how should you handle
multiple active processor cores running parallel threads? 

> > So, currently, a bookmarks mechanism seems to make the most sense. I think
that
> > most of the issues we have can be solved at the user-level:
> >
> > * Always take a bookmark when you start (which normally for is not time
zero,
> > but rather some arbitrary point in time of the target system when the
reverse
> is
> > turned on).
> >
> > * Allows the backend to push bookmarks. In that way, you just set up a
script
> or
> > module that sends bookmarks to gdb at a regular pace in target time (say
every
> 1
> > microsecond on the target side or whatever).
> >
> > * Your frontend scripts can then rely on these bookmarks.
> >
> > Not super-solid, but it works with a simple bookmark mechanism and keeps
time
> > internal to the backend.
> 
> All of the above sounds good to me.
> 
> However, I still reckon a pair or commands simply to get and set the
> time as a scalar value should be both useful for the user, and  trivial
> to implement (he said, confidently :-)  It could be orthogonal to
> bookmarks (a way to convert bookmarks to scalar time value would be
> useful, but not essential to start with).
> 
> We should probably pipe up with some patches, but I'm just slightly
> nervous that I may have missed something, especially as I'm not really
> terribly au fait with gdb's internals and its assumptions (hence the
> discussion first).

Me neither...

/jakob

Re: Simics & reverse execution

[Greg Law]

On 09/07/2009 09:24 AM, Jakob Engblom wrote:
>>> going to be painful.  Time really becomes very pervasive once
>>> you start using it in one place...
>>
>> Intriguing.  In what ways?
>>
>> We currently have a somewhat baroque bunch of python that wraps up
>> gdb to enable our reverse debugging commands on users system where
>> they've an older version of gdb installed.  This includes some
>> commands to display the current time and jump to an arbitrary time
>> (where time is a scalar 64-bit integer).  The rest of gdb remains
>> blissfully unaware (obviously, since it's unpatched).
>>
>> I can see how in general "teaching" the concept of time to gdb
>> would be a huge job.  But I don't think a command to jump around
>> arbitrarily and another to display the "current" time needs to
>> teach anything about time to the rest of gdb.
>
> Think about the cross-product with thread handling.  If you use time
> there, you need to determine how to handle times for threads. One
> timeline per thread? Or a global system time?

Oh right, yes, I was assuming global.

If time were per thread, then yes, I can see how that would quickly get
very complicated.

>
> You also really like to have time breakpoints in the system, to
> allow you to do things like "run this system for 6.132 seconds and
> then stop" (typical operation we do when skipping a boot sequence or
> we have run a workload several times and know when itneresting
> things should start to happen).

I would argue that's a future feature.  Time-based breakpoints would
seem a very nice thing to have, but a system which had get/set time
commands but no time breakpoints would be a lot more more useful than
one with neither.

>
> Also, how should this interact with non-stop debug? And how should
> you handle multiple active processor cores running parallel threads?

I must confess, I haven't given much thought at all to the interaction
of non-stop debug with reverse debugging in general.  I haven't been
following too closely, but aren't they currently incompatible anyway?
(something to do with displaced breakpoints not working well with
reverse).  But I don't see how it's any worse than the bookmarks case.
In fact, I don't see how any of it differs from use with bookmarks.  All
we're really talking about is a different way to describe a point in
history.

Again, you could go a lot further than I'm proposing right now.  But
that's not to say you need to for this stuff be useful.

Greg

-- 
Greg Law, Undo Software                       http://undo-software.com/

RE: Simics & reverse execution

[Jakob Engblom]

> > Think about the cross-product with thread handling.  If you use time
> > there, you need to determine how to handle times for threads. One
> > timeline per thread? Or a global system time?
> 
> Oh right, yes, I was assuming global.
> 
> If time were per thread, then yes, I can see how that would quickly get
> very complicated.

And I think time is per-thread in process record, as that is based on
instruction counts.  Not to mention to synch time across multiple processors
which are executing in parallel... that is a very  non-trivial problem in
practice.
 
> > You also really like to have time breakpoints in the system, to
> > allow you to do things like "run this system for 6.132 seconds and
> > then stop" (typical operation we do when skipping a boot sequence or
> > we have run a workload several times and know when itneresting
> > things should start to happen).
> 
> I would argue that's a future feature.  Time-based breakpoints would
> seem a very nice thing to have, but a system which had get/set time
> commands but no time breakpoints would be a lot more more useful than
> one with neither.

True. And actually, if you "set" time to 6.132 seconds in my example, a smart
backend would do the same... execute until that point even if it was not already
executed. That's what Simics does, I think.
 
> > Also, how should this interact with non-stop debug? And how should
> > you handle multiple active processor cores running parallel threads?
> 
> I must confess, I haven't given much thought at all to the interaction
> of non-stop debug with reverse debugging in general.  I haven't been
> following too closely, but aren't they currently incompatible anyway?
> (something to do with displaced breakpoints not working well with
> reverse).  But I don't see how it's any worse than the bookmarks case.
> In fact, I don't see how any of it differs from use with bookmarks.  All
> we're really talking about is a different way to describe a point in
> history.

The problem is that different backends have different natural semantics here. 

A simulator has a natural semantic of synchronous stop across all processors,
devices, and everything else going on.  A hardware across JTAG is far more
likely to stop just a few cores and keep the rest running.  Hardware with
recording: ????

That's why an abstract bookmark concept is so appealing: it can hide anything in
the backend, and let it worry about setting up times on multiple processors,
multiple machines, or hardware recorders. 

> Again, you could go a lot further than I'm proposing right now.  But
> that's not to say you need to for this stuff be useful.

Yes, for us, a 64-bit integer count of time would be quite useful as a general
tool. 

/jakob

Re: Simics & reverse execution

[Greg Law]

Jakob Engblom wrote:
> [...]
 >
> The problem is that different backends have different natural semantics here. 
> 
> A simulator has a natural semantic of synchronous stop across all processors,
> devices, and everything else going on.  A hardware across JTAG is far more
> likely to stop just a few cores and keep the rest running.  Hardware with
> recording: ????
> 
> That's why an abstract bookmark concept is so appealing: it can hide anything in
> the backend, and let it worry about setting up times on multiple processors,
> multiple machines, or hardware recorders.

Ok, yes, I see what you're getting at here: bookmarks might be more
easily implemented in some targets than some global linear notion of
time.

> 
>> Again, you could go a lot further than I'm proposing right now.  But
>> that's not to say you need to for this stuff be useful.
> 
> Yes, for us, a 64-bit integer count of time would be quite useful as a general
> tool. 

Cool - so is the general agreement that a scalar notion of time is a
useful thing to add, even if it's not supported in all reversible
targets?  (And bookmarks is an (at least) equally useful notion.)

Greg
-- 
Greg Law, Undo Software                       http://undo-software.com/

RE: Simics & reverse execution

[Jakob Engblom]

> > That's why an abstract bookmark concept is so appealing: it can hide
anything
> in
> > the backend, and let it worry about setting up times on multiple processors,
> > multiple machines, or hardware recorders.
> 
> Ok, yes, I see what you're getting at here: bookmarks might be more
> easily implemented in some targets than some global linear notion of
> time.

Not quite... but it lets us get some use out of time in gdb without introducing
a time concept.  As I said, if we let the backend generate bookmarks, we can get
to any time precision we want by pushing bookmarks from the backend.  Withtout
gdb having to understnad time. 

Another issue with time is that once gdb knows about time, you have to be much
more careful when changing place in the program.  If jumping back and forth, you
have to make sure that gdb time is correctly updated.  Today, having a
state-less debugger makes this easier: we retrofitted (as I guess you did)
reverse execution on gdb quite easily since gdb had no notion of time.  Had
there been that, it would have been much more painful.
 
> >> Again, you could go a lot further than I'm proposing right now.  But
> >> that's not to say you need to for this stuff be useful.
> >
> > Yes, for us, a 64-bit integer count of time would be quite useful as a
general
> > tool.
> 
> Cool - so is the general agreement that a scalar notion of time is a
> useful thing to add, even if it's not supported in all reversible
> targets?  (And bookmarks is an (at least) equally useful notion.)

I think a scalar time is very useful. But I fear that implementing it will meet
with resistance and require quite drastic changes.  Bookmarks are probably
easier to introduce as a first step. That was what Michael Snyder said, and I
can agree with that.

Ideally, I DO want gdb to be time-aware, but that does require a lot of semantic
thinking for how time can and should interact with multiple threads, processor
cores, and reverse debug systems.

/jakob

Re: Simics & reverse execution

[Greg Law]

Jakob Engblom wrote:
>>> That's why an abstract bookmark concept is so appealing: it can hide
> anything
>> in
>>> the backend, and let it worry about setting up times on multiple processors,
>>> multiple machines, or hardware recorders.
>> Ok, yes, I see what you're getting at here: bookmarks might be more
>> easily implemented in some targets than some global linear notion of
>> time.
> 
> Not quite... but it lets us get some use out of time in gdb without introducing
> a time concept.  As I said, if we let the backend generate bookmarks, we can get
> to any time precision we want by pushing bookmarks from the backend.  Withtout
> gdb having to understnad time.

Ah, the discussion comes back to where we started :)

Sincere apologies if I'm being stupid here, but I'm still struggling to
understand you.  i.e. I still don't understand why "get-time/set-time"
commands require that gdb gains any notion of time.

You mentioned earlier that a target might want routinely to generate
bookmarks (e.g. every 10ms).  If that target numbered those bookmarks
1,2,3,4,etc then it would have exactly the notion of time that I'm
asking for here.

> 
> Another issue with time is that once gdb knows about time, you have to be much
> more careful when changing place in the program.  If jumping back and forth, you
> have to make sure that gdb time is correctly updated.  Today, having a
> state-less debugger makes this easier: we retrofitted (as I guess you did)
> reverse execution on gdb quite easily since gdb had no notion of time.  Had
> there been that, it would have been much more painful.

I don't follow.  If we had "get-time/set-time" commands, these could be
proxied by gdb straight to the target.  Thus gdb remains stateless in
this regard, and blissfully unaware of any notion of jumping around in
time.  All gdb needs to know is that "set-time" will change the
target's state, but that's no different to regular continue or step.

>  
>>>> Again, you could go a lot further than I'm proposing right now.  But
>>>> that's not to say you need to for this stuff be useful.
>>> Yes, for us, a 64-bit integer count of time would be quite useful as a
> general
>>> tool.
>> Cool - so is the general agreement that a scalar notion of time is a
>> useful thing to add, even if it's not supported in all reversible
>> targets?  (And bookmarks is an (at least) equally useful notion.)
> 
> I think a scalar time is very useful. But I fear that implementing it will meet
> with resistance and require quite drastic changes.  Bookmarks are probably
> easier to introduce as a first step. That was what Michael Snyder said, and I
> can agree with that.

Hopefully Michael can clarify, but I thought he was agreeing that we
don't want to teach gdb about the concept of time (not yet anyway),
which I also totally agree with.

My proposal is that a "timestamp" (i.e. what "get-time" returns) would
be very like a "bookmark", except:

(a) not precise like a bookmark (e.g. if "get-time" returns timestamp X,
then a subsequent "set-time" will take you close to time X, but not
necessarily exactly at time X)

(b) multiple timestamps can be compared to get an approximate idea of
their point in history relative to each other.  e.g. timestamp 20 would
come before 22 and 22 would come before 100, and also 22 is is much
closer to 20 than it is to 100.

> 
> Ideally, I DO want gdb to be time-aware, but that does require a lot of semantic
> thinking for how time can and should interact with multiple threads, processor
> cores, and reverse debug systems.

Note my emphasis on "user" above - I'm not talking about gdb making any
semantic interpretation of the timestamp.  It's just a number that gdb
displays to the user.  Opaque to gdb, but potentially meaningful to the
user.

Greg
-- 
Greg Law, Undo Software                       http://undo-software.com/

RE: Simics & reverse execution

[Jakob Engblom]

> > anything
> >> in
> >>> the backend, and let it worry about setting up times on multiple
processors,
> >>> multiple machines, or hardware recorders.
> >> Ok, yes, I see what you're getting at here: bookmarks might be more
> >> easily implemented in some targets than some global linear notion of
> >> time.
> >
> > Not quite... but it lets us get some use out of time in gdb without
introducing
> > a time concept.  As I said, if we let the backend generate bookmarks, we can
> get
> > to any time precision we want by pushing bookmarks from the backend.
Withtout
> > gdb having to understnad time.
> 
> Ah, the discussion comes back to where we started :)
> 
> Sincere apologies if I'm being stupid here, but I'm still struggling to
> understand you.  i.e. I still don't understand why "get-time/set-time"
> commands require that gdb gains any notion of time.

I think that is safe... but Michael Snyder was very clear that this had some
major issues as I understood it? 
 
> You mentioned earlier that a target might want routinely to generate
> bookmarks (e.g. every 10ms).  If that target numbered those bookmarks
> 1,2,3,4,etc then it would have exactly the notion of time that I'm
> asking for here.

Yes, but it is done without any time representation at the gdb side of things. 

> I don't follow.  If we had "get-time/set-time" commands, these could be
> proxied by gdb straight to the target.  Thus gdb remains stateless in
> this regard, and blissfully unaware of any notion of jumping around in
> time.  All gdb needs to know is that "set-time" will change the
> target's state, but that's no different to regular continue or step.

Yes, but it does invite for time to become more part of the state. 

Note that I am all for this, but I can see how it quickly degenerates into a
major design issue with 

""get-time -thread x" ... how is THAT done?" ... etc ...
 
> 
> Hopefully Michael can clarify, but I thought he was agreeing that we
> don't want to teach gdb about the concept of time (not yet anyway),
> which I also totally agree with.

OK. All on the same plate. 
 
> My proposal is that a "timestamp" (i.e. what "get-time" returns) would
> be very like a "bookmark", except:
> 
> (a) not precise like a bookmark (e.g. if "get-time" returns timestamp X,
> then a subsequent "set-time" will take you close to time X, but not
> necessarily exactly at time X)

Interesting idea to make this fuzzy. I can see a problem with this: unless your
backend has its own UI where you CAN check the precise time, this invites user
confusion. I often find myself carefully stepping back and forth very precise
cycle counts to observer what is going on... and this fuzzy time would not let
me do that.  It also means that when execution stops after a "set-time" command,
you really don't know where you are :)
 

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
________________________________________________________
  

/jakob

Re: Simics & reverse execution

[Michael Snyder]

Jakob Engblom wrote:
>>> anything
>>>> in
>>>>> the backend, and let it worry about setting up times on multiple
> processors,
>>>>> multiple machines, or hardware recorders.
>>>> Ok, yes, I see what you're getting at here: bookmarks might be more
>>>> easily implemented in some targets than some global linear notion of
>>>> time.
>>> Not quite... but it lets us get some use out of time in gdb without
> introducing
>>> a time concept.  As I said, if we let the backend generate bookmarks, we can
>> get
>>> to any time precision we want by pushing bookmarks from the backend.
> Withtout
>>> gdb having to understnad time.
>> Ah, the discussion comes back to where we started :)
>>
>> Sincere apologies if I'm being stupid here, but I'm still struggling to
>> understand you.  i.e. I still don't understand why "get-time/set-time"
>> commands require that gdb gains any notion of time.
> 
> I think that is safe... but Michael Snyder was very clear that this had some
> major issues as I understood it? 

What I think I said was that gdb doesn't currently have any knowledge
about time, and that I don't believe it needs to (other than to do
what you specifically want to do).

>> You mentioned earlier that a target might want routinely to generate
>> bookmarks (e.g. every 10ms).  If that target numbered those bookmarks
>> 1,2,3,4,etc then it would have exactly the notion of time that I'm
>> asking for here.
> 
> Yes, but it is done without any time representation at the gdb side of things. 

This is not what I had in mind when I said "bookmark".
I can see the utility of this concept, but I'd rather
call it something else to distinguish the two.

The concept that I was thinking about as "bookmark" was a
relatively small number of discrete points in the execution
trace that gdb would keep track of in a list, in response to
explicit, discrete user requests.  Like breakpoints or checkpoints.

Something that the target generates a large number of, automatically
or at discrete intervals or something, sounds to me a little more
similar to tracepoints.  Maybe we could talk about using something
a little more like tracepoint semantics for that.

>> I don't follow.  If we had "get-time/set-time" commands, these could be
>> proxied by gdb straight to the target.  Thus gdb remains stateless in
>> this regard, and blissfully unaware of any notion of jumping around in
>> time.  All gdb needs to know is that "set-time" will change the
>> target's state, but that's no different to regular continue or step.
> 
> Yes, but it does invite for time to become more part of the state. 

It's a hell of an interesting idea -- I can certainly understand
why you're interested in it.  But I don't think it's a requirement,
for the simple concept of bookmarks.

> 
> Note that I am all for this, but I can see how it quickly degenerates into a
> major design issue with 
> 
> ""get-time -thread x" ... how is THAT done?" ... etc ...
>  
>> Hopefully Michael can clarify, but I thought he was agreeing that we
>> don't want to teach gdb about the concept of time (not yet anyway),
>> which I also totally agree with.
> 
> OK. All on the same plate. 
>  
>> My proposal is that a "timestamp" (i.e. what "get-time" returns) would
>> be very like a "bookmark", except:
>>
>> (a) not precise like a bookmark (e.g. if "get-time" returns timestamp X,
>> then a subsequent "set-time" will take you close to time X, but not
>> necessarily exactly at time X)
> 
> Interesting idea to make this fuzzy. I can see a problem with this: unless your
> backend has its own UI where you CAN check the precise time, this invites user
> confusion. I often find myself carefully stepping back and forth very precise
> cycle counts to observer what is going on... and this fuzzy time would not let
> me do that.  It also means that when execution stops after a "set-time" command,
> you really don't know where you are :)
>  
> 
> 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
> ________________________________________________________
>   
> 
> /jakob
> 
>