From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17112 invoked by alias); 16 Jun 2005 23:30:15 -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 17062 invoked by uid 22791); 16 Jun 2005 23:30:05 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 16 Jun 2005 23:30:05 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j5GNU31D008181 for ; Thu, 16 Jun 2005 16:30:03 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Thu, 16 Jun 2005 16:30:03 -0700 Received: from [17.201.22.21] (moleja.apple.com [17.201.22.21]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id j5GNU1mI026204; Thu, 16 Jun 2005 16:30:02 -0700 (PDT) In-Reply-To: <17074.1440.40908.588287@farnswood.snap.net.nz> References: <17072.62436.183299.55978@farnswood.snap.net.nz> <50B12BF2-9C7D-43ED-AF21-D1EA42AC7115@apple.com> <17074.1440.40908.588287@farnswood.snap.net.nz> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <412387CD-8F52-46E0-865F-560543C1E757@apple.com> Cc: gdb-patches@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jason Molenda Subject: Re: [PATCH] -stack-select-frame Date: Thu, 16 Jun 2005 23:30:00 -0000 To: Nick Roberts X-SW-Source: 2005-06/txt/msg00229.txt.bz2 On Jun 16, 2005, at 4:05 PM, Nick Roberts wrote: > 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". (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"} we have similar timestamps put out by the GUI so when there's a slowdown we can establish where time was being spent.) >>> enum mi_cmd_result >>> mi_cmd_stack_select_frame (char *command, char **argv, int argc) >>> { >>> - if (!target_has_stack) >>> - error (_("mi_cmd_stack_select_frame: No stack.")); >>> - >>> > > Because now GDB will report it as follows: > > -stack-select-frame > &"No stack.\n" > ^error,msg="No stack." > (gdb) You're right, currently it behaves like this: -stack-select-frame &"mi_cmd_stack_select_frame: No stack.\n" ^error,msg="mi_cmd_stack_select_frame: No stack." (gdb) but select_frame_command () will throw the error eventually, so there's no need to do the additional check here. J