From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24823 invoked by alias); 24 Sep 2005 00:46:27 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 24792 invoked by uid 22791); 24 Sep 2005 00:46:17 -0000 Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 24 Sep 2005 00:46:17 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j8O0kBoe022290; Fri, 23 Sep 2005 17:46:11 -0700 (PDT) Received: from [17.219.207.38] (unknown [17.219.207.38]) by relay6.apple.com (Apple SCV relay) with ESMTP id CBD594AF; Fri, 23 Sep 2005 17:46:10 -0700 (PDT) Message-ID: <4334A1D3.2030309@apple.com> Date: Sat, 24 Sep 2005 00:46:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050915 MIME-Version: 1.0 To: Michael Snyder Cc: Ian Lance Taylor , Eli Zaretskii , gdb@sources.redhat.com Subject: Re: Using reverse execution References: <43309387.4020504@cisco.com> <4331C468.3080204@cisco.com> In-Reply-To: <4331C468.3080204@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00178.txt.bz2 Michael Snyder wrote: > Ian Lance Taylor wrote: > >> Eli Zaretskii writes: >> >> >>>> Cc: gdb@sources.redhat.com, shebs@apple.com >>>> From: Ian Lance Taylor >>>> 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). Stan