From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14698 invoked by alias); 21 Sep 2005 17:52:13 -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 14677 invoked by uid 22791); 21 Sep 2005 17:52:04 -0000 Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 21 Sep 2005 17:52:04 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-38-167.inter.net.il [80.230.38.167]) by romy.inter.net.il (MOS 3.5.8-GR) with ESMTP id CLM42557 (AUTH halo1); Wed, 21 Sep 2005 20:51:56 +0300 (IDT) Date: Wed, 21 Sep 2005 17:52:00 -0000 Message-Id: From: Eli Zaretskii To: Ian Lance Taylor CC: michsnyd@cisco.com, gdb@sources.redhat.com, shebs@apple.com In-reply-to: (message from Ian Lance Taylor on 20 Sep 2005 20:59:58 -0700) Subject: Re: Using reverse execution Reply-to: Eli Zaretskii References: <43309387.4020504@cisco.com> X-SW-Source: 2005-09/txt/msg00160.txt.bz2 > Cc: michsnyd@cisco.com, gdb@sources.redhat.com, shebs@apple.com > From: Ian Lance Taylor > Date: 20 Sep 2005 20:59:58 -0700 > > 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. We've all used some kind of logging system to debug real-time or near real-time programs---because that's about the only way to debug them, if you don't have something like tracepoints. (Well, there's also oscilloscope debugging for hard real-time programs, if you know what I mean ;-) However, debugging through a logging system is akin to printf debugging; it has all the same deficiencies: the need to recompile the program to add logging code, which could cause some hard Heisenbugs to change behavior or even go away, due to code changes and timing changes. > (I had several communicating programs with real time interactions. I > arranged for each one to spit out log lines into a separate > multilog-like program to add timestamps, and then after the fact > sorted the lines together to see what was happening.) Yep, been-there-done-that. > Obviously I'm not saying that tracepoints should be removed or > anything like that. I'm just responding to Stan's comment that > tracepoints have been around for a while and not used, by mentioning > that I personally never seen any important use for them. You will find in the archives that I said a few years ago that native tracepoints is a feature to kill for. Not surprisingly, at the time I was working on a large real-time software project. A sophisticated logging system, augmented by deliberate abort-core-dump code in strategic places was the best replacement I came up with. That was on an SGI machine that needed to respond to an interrupt and run the application code that serviced the interrupt within 500 microseconds. I used a scope to convince myself that this hard real-time requirement was being met.