From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12404 invoked by alias); 17 Jul 2006 21:11:10 -0000 Received: (qmail 12395 invoked by uid 22791); 17 Jul 2006 21:11:09 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 17 Jul 2006 21:11:05 +0000 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k6HLB1KP029202; Mon, 17 Jul 2006 14:11:01 -0700 (PDT) Received: from [17.201.22.240] (unknown [17.201.22.240]) by relay8.apple.com (Apple SCV relay) with ESMTP id 638BB4B3; Mon, 17 Jul 2006 14:11:01 -0700 (PDT) Date: Mon, 17 Jul 2006 22:00:00 -0000 Content-Transfer-Encoding: 7bit Cc: gdb@sourceware.org, dmi-discuss@lists.freestandards.org From: Jim Ingham In-Reply-To: <17593.30235.462941.279388@kahikatea.snap.net.nz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Subject: Re: MI: event notification References: <17560.40409.61785.698765@kahikatea.snap.net.nz> <20060621013437.GA17956@nevyn.them.org> <17560.44395.508930.351917@kahikatea.snap.net.nz> <20060621023258.GA19167@nevyn.them.org> <0DEBAC0A-BF26-414A-ABE6-DFE5105A684C@apple.com> <17593.30235.462941.279388@kahikatea.snap.net.nz> To: Nick Roberts Mime-Version: 1.0 (Apple Message framework v821) Message-Id: X-Mailer: Apple Mail (2.821) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00120.txt.bz2 On Jul 15, 2006, at 4:11 PM, Nick Roberts wrote: > Jim Ingham writes: >> We don't do what Nick's suggesting. We do do something similar for >> shared library notifications - we emit async notifications for shared >> library load events from gdb so Xcode doesn't have to stop on solib >> events & get the shlig list. Similarly if a shared library load >> causes a pended breakpoint to get loaded we tell about that as well. >> >> But we don't do anything for stack changes. Note, except in the case >> where you have gotten stuck in some kind of pathological recursion, I >> would be surprised if it's consing up the stack list for the MI that >> takes a significant portion of the time, so I'm not sure this example >> isn't a false optimization. But anyway, we don't do that. > > I thought previous discussion (Vladimir Prus) suggested that > -stack-list-argments, at least, was time consuming. If the stack is > 1000's of > frames deep, it must surely be time comsuming to compute and re- > display it at > every step. The depth can be restricted but I think you have said > that the > first ones take are the hardest to compute. We have a simple backtracer that just follows the frame pointer, and doesn't do any of the fancy unwinding of registers, etc. When I get it to print roughly the same information as the ordinary -stack-list- frames it's ~10 times faster than -stack-list-frames. So I'm pretty sure most of the time in -stack-list-frames is doing real work computing the backtrace, and only a small portion is consing up the output. To tell whether the stack has changed or not you have to do the backtrace (even if you don't report it.) So my guess is this change wouldn't save very much time. The shared-libraries one was a win because we got the UI out of the process of stopping & starting again on shared library hit. For > > In any case, we need to be scientific about it, so I propose to add > a time > field to the MI output. ISTR that Apple's MI already has this. Are > you > planning to include this (or the async notifications for shared > librarys) in > the DMI specification? I would like to avoid unnecessary > duplication of > effort. Dunno if the timing belongs in the spec, since it's more of a diagnostic thing. But it is really handy to have... The shared library notification is really useful and probably should go in. Jim