Re: [RFA] Reverse Debugging, 1/5

[Pedro Alves <pedro at codesourcery dot com>]

On Monday 06 October 2008 23:11:14, Michael Snyder wrote:

> Where I've been saying "target" in this thread, I
> have been meaning "the target_ops implementation",
> eg. (but not limited to) remote.c

"target" is such an overloaded word in GDB lingo ...

> > The question to me is --- when/why does the target (as in, the debug
> > API abstraction) ever need to know about the current direction that
> > it couldn't get from the core's request?
> 

> At this interface layer, the core's requests look like:
> 
>    target_set_exec_dir
>    target_resume
>    target_wait
>    [repeat]
>    target_set_exec_dir
> 
> So there may be many resume/wait calls between calls to set_exec_dir.
> This means that the target_ops module MUST remember the state, whether
> or not the core remembers it also.

That's all nice and pretty, for sync.  For async, you'll
have:

<event loop>
    command
      target_set_exec_dir
      target_resume
<event loop>
    target_wait
    target_resume
<event loop>
    target_wait
    target_resume
    target_set_exec_dir
<event loop>

At some point, if you support more than one inferior behind the
target_ops interface, you'll start asking yourself "why didn't I
make the interfaces fully complete and go rely on global state?"

Or even, in the single-inferior case:

<event loop>
    command
      target_set_exec_dir
      target_resume
<event loop>
    target_wait
    target_resume
    target_set_exec_dir
<event loop>
    target_wait
    handle_inferior_event
      error >>>>>>>>>> what's the target execution
            >>>>>>>>>> state after this, where was it stored?
<event loop>

But it's OK, we can always come back to this later, because
you're making the remote protocol stateless, which is good
enough for me for now.  ;-)

-- 
Pedro Alves