RE: GDB MI Reverse Commands added [2 of 3]

["Jakob Engblom" <jakob@virtutech.com>]

> Yes, that's ok.  But I'm struggling to think of a plausible way in which
> a target could provide reverse debugging without some kind of log.  Any
> stateful program will clobber its state as it runs, and so to go
> backwards you need to have a log somewhere that tells you what the state
> was before you clobbered it.  And it will not be possible to go
> backwards to a time before you started recording.

Easy. Deterministic replay. In the case we are reversing a Simics session that
has no asynch IO from the outside world, there is no log being used. We are just
replaying the same execution scenario from the start.  Typical example: initial
boot of a system.  First, U-Boot comes up, receives scripted input, and fires
off a Linux kernel, which also will not communicate with anything uncontrolled
until the serial terminal is up at the end of the boot. Until that time,
everything is under simulator control and can be replayed without using a log --
all parts of the system, including the network and the simulated DHCP server,
are deterministic in the strongest sense.

So, no, a "log" is not necessarily the implementation of reversible debug.

Normally, a log IS involved if you have asynch interaction with the outside
world, but there are many useful simulations that do not do that. 


A second question here: to me, "inferior" means whatever is being debugged. Is
that a correct interpretation?  So "inferior" can be a piece of firmware, an
operating system, or any other sequence of code to which gdb is attached?  I
think that some people tend to think of it as user-level programs, which is the
common case on desktops, but in the embedded world where I live, most often the
inferior is an entire system... and the user programs might be discovered only
in the debugger UI that faces the user, while gdb is used to communicate with
the taraet machine.  

So I think of "inferior" as not just user programs. Is that OK?

/jakob