Re: GDB record patch 0.1.3.1 for GDB-6.8 release

[Pedro Alves <pedro at codesourcery dot com>]

A Sunday 08 June 2008 07:53:14, teawater wrote:
> Cool. This idea is so cool.
> In before, I tried to make clear about the "strata", but I gave up.
> Now, I know this thing is so cool.

> But it let me very puzzled that which way is the best.
> The way that I used in before, I have done a a lot of things on it.

Don't worry, it's really more about code reorganization, than
rewriting.  :-)

You have two major components in your patch.

 1 - The record/replay component
 2 - The inferior control in reverse execution mode.

I'm suggesting to split those up, and make them communicate
with an abstracted interface (target methods).  In addition,
make the record support a layer on top of the
forward-execution-only debugging targets (of course, defering
much to the arch support).

> And it can be used.
> The way that use a special target for record, I think this way look
> professional.
> Please tell me your idea about it. Thanks a lot.

My idea is that support for reverse execution should be exposed by
target methods and properties.  Say target_can_reverse_p (),
target_set_execution_direction (...) or similar.  For native
debugging, it might be possible to share most of the code
between similar targets.

So, in a native linux debugging session, with record activated, the
target stack would look this (ignoring the thread layer), top to
bottom:

target       |     stratum      |  supports reverse  |   Notes
-------------+------------------+--------------------+-------------
record       | record_statum    |       1            |    (1)
linux native | process_stratum  |       0            |     -
exec target  | file_stratum)    |       0            |     -

(1) encapsulates the recording and replaying of events. 

Since record is on top, it answers the calls to target_can_reverse_p,
target_wait, etc.

In a remote debugging session, where the remote side does not support
recording, it should be possible to do the recording in the GDB side:

target       |     stratum      |  supports reverse  |   Notes
-------------+------------------+--------------------+-------------
record       | record_statum    |       1            |     -
remote       | process_stratum  |       0            |     (2)
exec target  | file_stratum)    |       0            |     -

(2) - GDB claims support for remote protocol reverse debugging
extensions, but the remote side didn't support them.

E.g.:  Connect to an x86-linux gdbserver, and support reverse
execution the same way you support recording native debugging.
E.g., you may need to force single-stepping in
record_resume, even if the upper layer didn't request it, I'd
leave that to you :-)


target       |     stratum      |  supports reverse  |   Notes
-------------+------------------+--------------------+-------------
remote       | process_stratum  |       1            |     (3)
exec target  | file_stratum)    |       0            |     -

(3) - GDB claims support for remote protocol reverse
debugging extensions, and the remote side also claimed support.

This would be the prefered method to support reverse execution
when GDB is connected to a simulator or emulator.  GDB would
tell the remote "reverse step", and the remote end would
take care of the reverse replaying.

Another alternative, is to fold the record support
into the process_stratum layer, but it doesn't look as
clean:

target       |     stratum      |  supports reverse  |   Notes
-------------+------------------+--------------------+-------------
linux native | process_stratum  |       1            |     (4)
exec target  | file_stratum)    |       0            |     -

(4) Manages the recording and replaying itself, by defering
to the record component.

I'd prefer the separation into a new layer if it is possible
at all.

This imposes a requirement that the common code doesn't
know about the record target's internals, but instead relies on
target methods and properties.  E.g. in infrun.c, instead of
checking your record variables directly, you'd check for
say, target_execution_direction () == EXEC_DIRECTION_REVERSE.

I have no idea how feasible is this.  This is just my
gut feeling about it.  As I said, take this as an investigation
suggestion.  :-)

What do others think?

-- 
Pedro Alves