From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13438 invoked by alias); 20 Sep 2011 05:32:14 -0000 Received: (qmail 13429 invoked by uid 22791); 20 Sep 2011 05:32:12 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Sep 2011 05:31:56 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1R5svz-00078r-L3; Tue, 20 Sep 2011 01:31:55 -0400 Date: Tue, 20 Sep 2011 05:42:00 -0000 Message-Id: From: Eli Zaretskii To: dje@google.com (Doug Evans) CC: gdb-patches@sourceware.org In-reply-to: <20110920041137.A67D02461A0@ruffy.mtv.corp.google.com> (dje@google.com) Subject: Re: [RFA, doc RFA] Include wallclock time in "maint time" output. Reply-to: Eli Zaretskii References: <20110920041137.A67D02461A0@ruffy.mtv.corp.google.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00370.txt.bz2 > Date: Mon, 19 Sep 2011 21:11:37 -0700 (PDT) > From: dje@google.com (Doug Evans) > > It is often useful to see the wallclock time of commands. Actually, it would be much more useful to display time it took the inferior between two points where GDB gets control. Are you trying to approximate that missing feature, or is there some other use case where wallclock time would be useful? > This patch adds wallclock time to the output from "maint time 1". > > This patch depends on a patch for libiberty, pending approval. > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01118.html > I'll revise this as appropriate, but can I get an RFA on the > addition of wallclock time to the output? > > [Other bits of gdb can make use of timeval-utils.h, > that's another patch.] IMO, it would be better to add to libiberty a couple of functions to measure interval times. What you suggest is to call gettimeofday twice and then subtract the values. But that assumes the resolution of gettimeofday is high enough to be useful in this paradigm, which might be true on Posix platforms (specifically GNU/Linux), but is not at all guaranteed elsewhere. For example, Windows lacks gettimeofday altogether and the emulation we use (from libiberty) has 1-sec(!) resolution. By contrast, it _is_ possible on Windows to measure intervals with sub-millisecond resolution. IOW, if we want an interval timing abstraction, let's have an API for that, instead of exposing the implementation which might make no sense on some platforms. > +If set to a nonzero value, @value{GDBN} will display how much time it > took to execute each command, following the command's own output. > -The time is not printed for the commands that run the target, since > -there's no mechanism currently to compute how much time was spend > -by @value{GDBN} and how much time was spend by the program been debugged. > -it's not possibly currently I'm not sure we should remove that remark, because what it says is still true, even after your changes. > +Both cpu time and wallclock time are printed. "CPU" in caps, or maybe "@sc{cpu}" (look at the PDF to decide which one you like best). > +Note that the cpu time printed is for @value{GDBN} only, it does not include > +the execution time of the inferior. Ditto. Thanks.