This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Reverse Debugging, 1/5
- From: Michael Snyder <msnyder at vmware dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Daniel Jacobowitz <drow at false dot org>, Pedro Alves <pedro at codesourcery dot com>, teawater <teawater at gmail dot com>
- Date: Mon, 06 Oct 2008 14:00:37 -0700
- Subject: Re: [RFA] Reverse Debugging, 1/5
- References: <48E3CCB6.4060501@vmware.com> <20081006203021.GA21853@adacore.com>
Joel Brobecker wrote:
2008-09-30 Michael Snyder <msnyder@vmware.com>
Target interface for reverse debugging.
* target.h (enum target_waitkind):
Add new wait event, TARGET_WAITKIND_NO_HISTORY.
(enum exec_direction_kind): New enum.
(struct target_ops): New methods to_set_execdir, to_get_execdir.
* target.c (target_get_execdir): New generic method.
(target_set_execdir): Ditto.
One of the questions I'm asking myself is why having the get_execdir
method? It seems that, once we have called "target_sets_execdir" and
it hasn't returned ERROR, core GDB should know what the execution
direction is, no? Is there a situation where a round-trip to the
target would be necessary? Otherwise, we'll end up with the target
code all doing the same thing, which is caching the current value
of the same thing.
One thing that crossed my mind while thinking about it is whether
we want to make this property global to all inferiors or specific
to each inferior. Ahem, shall we say global?
It was a design choice.
There were two choices:
1) modify target_resume (ops->to_resume), to add a direction
parameter.
2) Add a to_set_direction target method.
The first would have required modifying all existing targets,
so I chose the second.
Once you have a "set" method, it seems logical to have a
"get" method.
Making no assumptions about HOW the target sets the direction,
it seems likely that at least *some* targets will have to
remember this state locally. Whereas there is no reason
for core-gdb to have to remember the state locally, if it can
always get it from the target.
It seems a worse duplication to keep the same state information
simultaneously in the target and in the core, since now you
have to worry about them getting out of sync.
At worst, a target will need to maintain an int's worth of state
locally, and so long as we're never running two targets at the
same time, there's no synchronization issue.