[RFA] Reverse Debugging, 1/5
Pedro Alves
pedro@codesourcery.com
Mon Oct 6 22:35:00 GMT 2008
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
More information about the Gdb-patches
mailing list