This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Reverse Debugging, 1/5


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.


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