Re: Using reverse execution

[Michael Snyder <michsnyd@cisco.com>]

Stan Shebs wrote:
> Michael Snyder wrote:
> 
>> Ian Lance Taylor wrote:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>
>>>>> Cc: gdb@sources.redhat.com, shebs@apple.com
>>>>> From: Ian Lance Taylor <ian@airs.com>
>>>>> Date: 20 Sep 2005 16:13:55 -0700
>>>>>
>>>>> There is probably some cool use for which tracepoints are the
>>>>> obvious right answer, but I don't know what it is.
>>>>
>>>>
>>>>
>>>> In native debugging, tracepoints would be very useful to debug a
>>>> real-time program, or, more generally, a program where timing issues
>>>> are crucial to its correct operation.  With such programs, normal GDB
>>>> usage disrupts the program operation and might even cause the program
>>>> to fail in ways that are unrelated to the bug you are looking for.
>>>
>>>
>>>
>>>
>>> I get that that is the idea, it's just that I wouldn't tackle that
>>> problem that way.  I would put a logging framework in the program
>>> itself.  That's how I've debugged this sort of issue in the past, and
>>> the logging framework generally pays off for itself over time.
>>
>>
>>
>> That's what tracepoint debugging is, Ian -- it's a re-usable
>> logging framework.  It just frees you up from having to write
>> that logging code over and over into different projects, and
>> recompile your project whenever you want to log something
>> different.
>>
>> Well, that and a way-cool interactive data review and
>> presentation mode.   ;-)
>>
>> But let's not highjack this thread to talk about tracepoints,
>> unles it's to compare their use and utility to reverse execution.
> 
> 
> Ian does touch on an important general point, which is that
> debugger features ought to be uniquely available, not just
> repackaging of functionality that can be accomplished nearly
> as well in other ways.
> 
> For instance, when I have a plain old breakpoint that lets me stop
> and interactively look at a backtrace, that is something that is
> (usually) not possible to do without the help of a debugger, and
> everybody agrees that this is a good feature to have.
> 
> Conversely, if I have a tracepoint that just prints out one of my
> program's variables, that doesn't give me much that I can't get
> with a printf. However, if the tracepoint is collecting raw
> registers, that's more difficult to manage using only print
> functions, and then the tracepoint starts to looks more interesting.
> Ditto if I'm in a context where printf is not available, or so slow
> that it affects critical real-time behavior.
> 
> In the case of reverse execution, one Appleite wondered why anybody
> would bother, since you could repeatedly start the program over. And
> indeed, GDB makes the restarting process pretty quick and easy; just
> type "r". So reverse execution is not going to be a must-have unless
> rerunning is either impossible (as in the case of intermittent bugs),
> or very slow (as in the case of spending fifteen minutes giving
> iTunes a particular pattern of mouse clicks and CD insertions, just
> to get to the failing code).

No, it's not terribly useful for easy problems.
What do the Marines say?  The difficult we do immediately...