[RFA] Reverse debugging, part 3/3: user interface / docs

[Michael Snyder]

Eli Zaretskii wrote:
>>Date: Mon, 17 Apr 2006 16:44:55 -0700
>>From: Michael Snyder <msnyder@redhat.com>
>>CC: gdb-patches@sources.redhat.com
>>
>>Please see revised patch, attached.
>>OK now?
> 
> 
> The corrections you made are okay, but you left two of my suggestions
> unhandled, please at least explain why.
> 
> 
>>>>+                                                 Behavior of 
>>>>+ asynchronous signals depends on the target environment.
>>>
>>>
>>>This is too vague.  Can we at least mention the possible behaviors, or
>>>just the most common/expected ones?  The reader should get some idea
>>>of what might happen.
> 
> You didn't change anything in response to this comment.

Well, I don't really have any idea what might happen --
and it's really out of GDB's hands.  The target might do
(almost literally) anything.  It might ignore asynchronous
signals completely.  It might record and reproduce them
faithfully.  It might stick them in randomly.

 From the research that I've done into other reverse-execution
implementations, this is an area that's not well understood by
anybody.


>>>>+ Run the program backward until control reaches the start of a
>>>>+ different source line
>>>
>>>
>>>Isn't it better to say
>>>
>>>  Run the program backwards until control reaches the first instruction
>>>  of a different source line
>>>
>>>?  In any case, "backwards", not "backward".
> 
> 
> You left "backward" in the text.

Um, yeah... Eli, the text already contains "backward" twice, and
"backwards" only once, including *both* phrases "search backward"
and "search backwards".  I'm not convinced one is more correct
than the other, nor that a consistant usage is demonstrated in
context.

That said, I guess I don't care all that strongly -- but "backward"
sounds more correct to me here.

If you like, I'll change it to "Run the program in reverse"...    ;-)