Re: [RFA] Reverse debugging, part 1/3: target interface

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Apr 19, 2006 at 11:26:11AM -0700, Michael Snyder wrote:
> +@item bc
> +@cindex @samp{bc} packet
> +Continue execution in reverse (if capable).  
> +@xref{Reverse Execution, ,Running programs backward}.
> +
> +Reply:
> +@xref{Stop Reply Packets}, for the reply specifications.
> +
> +@item bs
> +@cindex @samp{bs} packet
> +Single step in reverse (if capable).  
> +@xref{Reverse Execution, ,Running programs backward}.
> +
> +Reply:
> +@xref{Stop Reply Packets}, for the reply specifications.
> +

You designed the target interface so that it could return EXEC_ERROR,
"I don't support reverse execution".  But here you've got only bc and
bs; you've got no way to probe the remote target for reverse execution
support.

I realize you've got at least one already shipping stub for this; can
we still fix it, or should we assume that there will be at least one
target where the only way to find out is to try?  This seems to be
one of the stray FIXMEs in this code which really ought to be fixed
before we merge it:

+   /* FIXME: check target for capability.  */

I'm guessing you haven't tried this with a remote target that didn't
support it.  It looks like it would fail messily.


Are there other hard cases that should be discussed in the remote
protocol documentation, or handled by the protocol?  The first one that
comes to mind is "what do we do with threads" - is it ever going to be
relevant to do this in a multi-threaded system, and if so, are we going
to reverse all threads at once?


Oh, and refering to Stop Reply Packets is not complete for the reply;
that doesn't cover error codes.  For instance, you have one error code
designated to mean "no more history".  That should be in the
documentation, please.  I've only skimmed the patch; are there others?



-- 
Daniel Jacobowitz
CodeSourcery