From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21319 invoked by alias); 24 Sep 2005 01:10:04 -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 21282 invoked by uid 22791); 24 Sep 2005 01:09:53 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 24 Sep 2005 01:09:53 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 23 Sep 2005 18:09:52 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8O1945U023193; Fri, 23 Sep 2005 18:09:49 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 18:09:46 -0700 Received: from [128.107.165.235] ([128.107.165.235]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 18:09:45 -0700 Message-ID: <4334A759.9070805@cisco.com> Date: Sat, 24 Sep 2005 01:10:00 -0000 From: Michael Snyder User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 MIME-Version: 1.0 To: Stan Shebs CC: Ian Lance Taylor , Eli Zaretskii , gdb@sources.redhat.com Subject: Re: Using reverse execution References: <43309387.4020504@cisco.com> <4331C468.3080204@cisco.com> <4334A1D3.2030309@apple.com> In-Reply-To: <4334A1D3.2030309@apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00179.txt.bz2 Stan Shebs wrote: > 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). No, it's not terribly useful for easy problems. What do the Marines say? The difficult we do immediately...