This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA, doc RFA] Include wallclock time in "maint time" output.


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]