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

[Michael Snyder]

Daniel Jacobowitz wrote:
> 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.

Yes, I think I remarked on the need for that in comments.

> 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? 

No problem -- it's not actually shipping, or even promised.
This has been a rare, redhat-funded pure research project.   ;-)

Yes, I appreciate how lucky I am.  Thank you, oh employer mine.
[not that we don't hope to make money from it eventually...]

> 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.

Hmmmmm... ok, your guess is correct.

I propose a deal -- I'll try it, and if it does fail messily,
I will fix it.  If it doesn't, will you let me check it in
with the expectation of future enhancement?  I feel that for
a major new functionality, useability rather than completeness
should be the mark.

It's not like we're not going to add to what's been
implemented so far.

> 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?

I think in previous discussion, we have recognized that this is a
hard problem, and I have simply deferred addressing it.  I don't
even claim to know if it *can* be addressed.  I'd like to say,
we can now use this feature on the non-trivial subset of non-
threaded programs, and put threaded programs down as a hoped-
for future enhancement.


> 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. 

Well, yes, I thought about that -- but in fact, AFAICT there is
*no* documentation for error codes, and I didn't feel like starting
it.  Yes, I think we need some, but it's probably worth having a
discussion of how we would like to do it.

And, self-interest not withstanding, I don't think there's a good
reason for holding up this patch for lack of something that is
lacking throughout.

 > I've only skimmed the patch; are there others?

None that I'm deliberately withholding.   ;-)
I'm counting on you reviewers to help find any that I've overlooked.

Thanks for your review and feedback.