From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23435 invoked by alias); 1 Jan 2007 04:07:29 -0000 Received: (qmail 23427 invoked by uid 22791); 1 Jan 2007 04:07:29 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 01 Jan 2007 04:07:24 +0000 Received: from farnswood.snap.net.nz (p202-124-124-28.snap.net.nz [202.124.124.28]) by viper.snap.net.nz (Postfix) with ESMTP id 7C26D3D81CC; Mon, 1 Jan 2007 17:07:13 +1300 (NZDT) Received: by farnswood.snap.net.nz (Postfix, from userid 500) id 53B25627ED; Mon, 1 Jan 2007 04:05:01 +0000 (GMT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17816.34925.514170.51734@farnswood.snap.net.nz> Date: Mon, 01 Jan 2007 04:07:00 -0000 To: Mark Kettenis Cc: ghost@cs.msu.su, gdb-patches@sources.redhat.com Subject: Re: [PATCH] MI: new timing command In-Reply-To: <200612311609.kBVG9Fgh022431@brahms.sibelius.xs4all.nl> 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> <200612311524.kBVFObud010411@brahms.sibelius.xs4all.nl> <200612311609.kBVG9Fgh022431@brahms.sibelius.xs4all.nl> X-Mailer: VM 7.19 under Emacs 22.0.50.58 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: 2007-01/txt/msg00005.txt.bz2 > > >> > 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. > > > > Is this important? This timing is entirely for diagnostic purposes, > > so why try to make it work on every possible platform. We need to document > > that -enable-timing may fail, and that's it. > > The point is to use get_run_time() from -liberty and never worry about > portability again. Let's be realistic. This isn't a command for general users of GDB, it isn't even a command for general users of frontends to GDB. It's a command for developers of frontends to GDB which currently means just myself and Vladimir, and maybe a couple of others like Bob Rossi and Alain Magloire. I'm not familiar with get_run_time but I'm sure we all know getrusage through the time shell command. If the frontend appears to be slow I can see if that's due to MI or other things running on my system. I'm not sure that I can do that with get_run_time. I would like to start with getrusage and then when there are hoards of developers rushing to develop frontends for GDB using MI on Windows, I'll be happy to accommodate them. -- Nick http://www.inet.net.nz/~nickrob