From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28192 invoked by alias); 15 Jul 2006 23:12:43 -0000 Received: (qmail 28184 invoked by uid 22791); 15 Jul 2006 23:12:43 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 15 Jul 2006 23:12:40 +0000 Received: from kahikatea.snap.net.nz (p403-tnt1.snap.net.nz [202.124.111.149]) by viper.snap.net.nz (Postfix) with ESMTP id 96DDD774BB7; Sun, 16 Jul 2006 11:12:37 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 4D2D61D3550; Sun, 16 Jul 2006 11:11:24 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17593.30235.462941.279388@kahikatea.snap.net.nz> Date: Sun, 16 Jul 2006 04:34:00 -0000 To: Jim Ingham Cc: gdb@sourceware.org, dmi-discuss@lists.freestandards.org Subject: Re: MI: event notification In-Reply-To: <0DEBAC0A-BF26-414A-ABE6-DFE5105A684C@apple.com> 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> X-Mailer: VM 7.19 under Emacs 22.0.50.37 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/msg00101.txt.bz2 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. 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. -- Nick http://www.inet.net.nz/~nickrob