Re: [RFA] Reverse Debugging, 1/5

[Michael Snyder <msnyder@vmware.com>]

Daniel Jacobowitz wrote:
> On Mon, Oct 06, 2008 at 02:00:37PM -0700, Michael Snyder wrote:
>> 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.
> 
> The problem is, we're now talking about a multi-process GDB.  It's a
> small step from there to one using multiple targets automatically.  Is
> core GDB going to have to do the juggling / bookkeeping to keep
> direction in sync for all of them?  The granularity will depend on the
> backend...
> 
> If it's just a matter of changing the existing targets, then avoiding
> that on a branch makes sense - but updating everything in the mainline
> version makes sense too.

I guess I could be persuaded.  But I'm not, yet...

You're going to send "to_set_direction" to the target,
and then you're going to assume that you know what the
state is later on, rather than asking the target?  What
if the target gets it wrong?  Now you're out of sync.

If we do keep the direction-state in the core, where would
we put it?  In the ecs?  In a global variable in infrun?

I still feel as if it's only the target that KNOWS what
its direction state is -- it should tell gdb, rather than
have gdb make assumptions.