From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3526 invoked by alias); 17 Jun 2005 07:22:31 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3478 invoked by uid 22791); 17 Jun 2005 07:22:17 -0000 Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 17 Jun 2005 07:22:17 +0000 Received: from farnswood.snap.net.nz (p122-tnt1.snap.net.nz [202.124.110.122]) by viper.snap.net.nz (Postfix) with ESMTP id 4ACBB55C8DC; Fri, 17 Jun 2005 19:22:14 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 3F8F062A99; Fri, 17 Jun 2005 08:24:05 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17074.31377.996795.526839@farnswood.snap.net.nz> Date: Fri, 17 Jun 2005 07:22:00 -0000 To: Jason Molenda Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] -stack-select-frame In-Reply-To: <412387CD-8F52-46E0-865F-560543C1E757@apple.com> References: <17072.62436.183299.55978@farnswood.snap.net.nz> <50B12BF2-9C7D-43ED-AF21-D1EA42AC7115@apple.com> <17074.1440.40908.588287@farnswood.snap.net.nz> <412387CD-8F52-46E0-865F-560543C1E757@apple.com> X-SW-Source: 2005-06/txt/msg00245.txt.bz2 [Jason - Sorry if you get this twice. My first message bounced at RedHat, for some reason.] > > I thought it would save some time if the user doesn't need to see the > > whole stack. > > FWIW we've done a lot of careful timing analysis, and the back & > forth communication between our GUI and gdb is so fast as to be > pointless to optimize. We original considered adding special purpose > "give Xcode everything it needs to know at a breakpoint hit" type > commands but when we saw how fast the majority of MI commands can > execute & be parsed by the GUI, it was obvious that this was not a > useful area to optimize. And frankly, in my anecdotal experience, > MacOS X isn't the fastest OS at things like "two processes talking > over a pipe". You've clearly been more quantitative. With my limited resources, I'm just guessing what might work best. I've suggested to Daniel a change that, I hope, won't impact on Xcode. I think you have your own copy of GDB and, like you say, you don't really care, but I guess its best not to diverge more than necessary. > (one of the parts of this profiling which is especially useful is > that we have a "mi-timings-enabled" setting. When it's enabled, > every MI command reports how long gdb took to complete it, e.g. the > "time=" bit at the end here: > > -> 50-stack-list-frames 0 5 > <- 50^done,stack=[frame= > {level="0",addr="0x0009e7fc",fp="0xbfffe700",func=" [...] ,frame= > {level="5",addr="0x936265d0",fp="0xbfffeee0",func="-[NSApplication > run]"}],time= > {wallclock="0.14353",user="0.00584",system="0.00335",start="1118952348.0 > 03847",end="1118952348.147372"} Yes but what happens when the stack is much deeper, 20 or 30 say, like it can be when you you are debugging Emacs, or GDB for that matter? Nick