From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-47413-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 25837 invoked by alias); 28 Jan 2007 04:17:37 -0000
Received: (qmail 25827 invoked by uid 22791); 28 Jan 2007 04:17:36 -0000
X-Spam-Check-By: sourceware.org
Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (213.8.233.22)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 28 Jan 2007 04:17:30 +0000
Received: from HOME-C4E4A596F7 (IGLD-83-130-4-64.inter.net.il [83.130.4.64]) 	by nitzan.inter.net.il (MOS 3.7.3a-GA) 	with ESMTP id FXB51362 (AUTH halo1); 	Sun, 28 Jan 2007 06:17:18 +0200 (IST)
Date: Sun, 28 Jan 2007 04:17:00 -0000
Message-Id: <uejpfaipa.fsf@gnu.org>
From: Eli Zaretskii <eliz@gnu.org>
To: Nick Roberts <nickrob@snap.net.nz>
CC: gdb-patches@sources.redhat.com
In-reply-to: <17851.52589.491047.323275@kahikatea.snap.net.nz> (message from 	Nick Roberts on Sun, 28 Jan 2007 11:08:45 +1300)
Subject: Re: [PATCH] MI: new timing command
Reply-to: Eli Zaretskii <eliz@gnu.org>
References: <17814.10139.269708.848818@kahikatea.snap.net.nz> 	<u8xgp2wnm.fsf@gnu.org> 	<17814.58031.865155.682869@kahikatea.snap.net.nz> 	<umz541yqg.fsf@gnu.org> 	<20061231042547.GA3236@nevyn.them.org> 	<17815.18190.987950.612053@kahikatea.snap.net.nz> 	<20061231054946.GA4873@nevyn.them.org> 	<17815.27092.497145.908734@kahikatea.snap.net.nz> 	<20061231151527.GC16449@nevyn.them.org> 	<200612311524.kBVFObud010411@brahms.sibelius.xs4all.nl> 	<E1H12lf-0002Zf-GT@zigzag.lvk.cs.msu.su> 	<200612311609.kBVG9Fgh022431@brahms.sibelius.xs4all.nl> 	<17816.34925.514170.51734@farnswood.snap.net.nz> 	<E1H1GB1-0000Da-7F@fencepost.gnu.org> 	<17817.34304.221915.628057@kahikatea.snap.net.nz> 	<u1wmecb5c.fsf@gnu.org> 	<17836.26941.915573.399839@kahikatea.snap.net.nz> 	<u1wlpvca3.fsf@gnu.org> 	<17842.33386.836316.276127@kahikatea.snap.net.nz> 	<u1wlgbjwr.fsf@gnu.org> <17851.52589.491047.323275@kahikatea.snap.net.nz>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2007-01/txt/msg00562.txt.bz2

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 28 Jan 2007 11:08:45 +1300
> Cc: gdb-patches@sources.redhat.com
> 
> Well it was explained to me that get_run_time basically returns wallclock
> time when getrusage isn't defined.

Not necessarily.  Take a look at getruntime.c: it can use `times' when
that is available.  `times' returns the sum of user and system times,
not the wallclock time.

>  > I suggest to use gettimeofday to compute wallclock time on all
>  > platforms, and avoid using struct rusage in struct mi_timestamp,
>  > e.g. like this:
>  > 
>  >     struct mi_timestamp {
>  > 	struct timeval wallclock;
>  > 	struct timeval utime;
>  > 	struct timeval stime'
>  >     }
>  >
>  > Then in mi-main.c:timestamp you could copy the values from what
>  > getrusage returns to the utime and stime members of mi_timestamp, when
>  > getrusage is available, and if not, assign the value returned by
>  > get_run_time to members of utime.
> 
> Won't the members wallclock and utime be basically the same now?

Not if `times' is used in get_run_time.

> Would something like below work?  When getrusage isn't defined I just use
> wallclock.  There's no need to define utime or stime in this case as the
> values are always 0.

That would work, but I think we shouldn't lose the important case of
platforms which have `times'.