From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15917 invoked by alias); 17 Jun 2005 17:45:57 -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 15904 invoked by uid 22791); 17 Jun 2005 17:45:52 -0000 Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 17 Jun 2005 17:45:52 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j5HHjofD003514 for ; Fri, 17 Jun 2005 10:45:50 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 17 Jun 2005 10:45:48 -0700 Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id j5HHjktU020401 for ; Fri, 17 Jun 2005 10:45:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <1119003319.5434.ezmlm@sources.redhat.com> References: <1119003319.5434.ezmlm@sources.redhat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <195D52F1-9F52-4BCC-BCF9-9036F9CBEBF8@apple.com> Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: [PATCH] -stack-select-frame Date: Fri, 17 Jun 2005 17:45:00 -0000 To: gdb-patches@sources.redhat.com X-SW-Source: 2005-06/txt/msg00259.txt.bz2 On Jun 17, 2005, at 3:15 AM, gdb-patches-digest- help@sources.redhat.com wrote: > > > > [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. Yes, thats right. We would rather not introduce gratuitous divergences. > > >> (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="111895234 >> 8.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? You are right to worry about this a bit. Getting a full backtrace when the stack is deep can be expensive, especially when you do it every step. And using a complex kit like AppKit or Carbon where lots of the work is done through callbacks, etc, can lead to really deep stacks as well. OTOH, the stack window is sitting there open, so we have to keep it up to date. We got hit with this pretty early on in getting Xcode working. What we did was add another command (-stack-list-frames-lite) that just returns the pairs (pc/sp) for the current stack. You can usually implement this to run quite quickly on the target side without having to do the full register unwind, etc (*). Then every time we stop, Xcode calls this -stack-list-frames-lite, and compares the results with the stack it had before the target started up. Then it only needs to fetch the frames that have changed. For extra credit, it could not fetch the frames for any that aren't visible in the current stack window in the GUI, though Xcode hasn't done that yet. We still pay a cost when you arrive in a totally new stack. But since the target usually has to run a bit for the stack to change a lot, this cost gets mixed in with the target running, and doesn't create such a bad perceived slowness. But it removes most of the problems that stack tracing gave us when stepping, which is where a lag really annoys users. (*) I think Andrew's design of the frame caching stuff should make this unnecessary if the architecture specific unwinders were smart enough to only unwind the one register they were asked to every time. We haven't done that yet, but that's more an implememtation detail. Jim > > Nick >