From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16945 invoked by alias); 31 Dec 2006 15:24:57 -0000 Received: (qmail 16937 invoked by uid 22791); 31 Dec 2006 15:24:56 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 31 Dec 2006 15:24:52 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.13.8/8.13.8) with ESMTP id kBVFObsl026736; Sun, 31 Dec 2006 16:24:37 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id kBVFObud010411; Sun, 31 Dec 2006 16:24:37 +0100 (CET) Date: Sun, 31 Dec 2006 15:24:00 -0000 Message-Id: <200612311524.kBVFObud010411@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: nickrob@snap.net.nz, eliz@gnu.org, gdb-patches@sourceware.org In-reply-to: <20061231151527.GC16449@nevyn.them.org> (message from Daniel Jacobowitz on Sun, 31 Dec 2006 10:15:27 -0500) Subject: Re: [PATCH] MI: new timing command References: <17814.10139.269708.848818@kahikatea.snap.net.nz> <17814.58031.865155.682869@kahikatea.snap.net.nz> <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> 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: 2006-12/txt/msg00408.txt.bz2 > Date: Sun, 31 Dec 2006 10:15:27 -0500 > From: Daniel Jacobowitz > > On Sun, Dec 31, 2006 at 08:42:12PM +1300, Nick Roberts wrote: > > Daniel Jacobowitz writes: > > > In that case you can copy the necessary guards from that file. > > > However, it does more than just getrusage - it also supports > > > platforms with times() but without getrusage, which IIRC includes > > > Windows, so it might be better to use it. > > > > But as a last resort it returns elapsed time which would be wrong. > > You keep saying this but I don't see why. Why is it wrong? On every > platform where we can do it, we'll print usage; on platforms where we > can't do it, the odds are pretty good that the OS isn't aggressively > scheduling other tasks in while we're running, so wall time is pretty > close to right. I agree completely.