From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13884 invoked by alias); 17 Jun 2005 13:30:23 -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 13757 invoked by uid 22791); 17 Jun 2005 13:30:04 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 17 Jun 2005 13:30:04 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1DjGtZ-0006Fs-Ve; Fri, 17 Jun 2005 09:28:30 -0400 Date: Fri, 17 Jun 2005 13:30:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Jason Molenda , gdb-patches@sources.redhat.com Subject: Re: [PATCH] -stack-select-frame Message-ID: <20050617132829.GA23901@nevyn.them.org> Mail-Followup-To: Nick Roberts , Jason Molenda , gdb-patches@sources.redhat.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> <17074.31377.996795.526839@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17074.31377.996795.526839@farnswood.snap.net.nz> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-06/txt/msg00254.txt.bz2 On Fri, Jun 17, 2005 at 07:24:01PM +1200, Nick Roberts wrote: > > (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? Just a guess but: why ask GDB for more stack frames than fit in the relevant window? You can ask for more (to ensure smooth scrolling), but do it while the user's doing something else. An MI frontend doesn't need to ask for all frames if it's worried about how long that will take. -- Daniel Jacobowitz CodeSourcery, LLC