From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12933 invoked by alias); 7 Feb 2005 21:22:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12846 invoked from network); 7 Feb 2005 21:21:59 -0000 Received: from unknown (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org with SMTP; 7 Feb 2005 21:21:59 -0000 Received: from farnswood.snap.net.nz (p131-tnt1.snap.net.nz [202.124.110.131]) by viper.snap.net.nz (Postfix) with ESMTP id 819743402B7; Tue, 8 Feb 2005 10:21:57 +1300 (NZDT) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 2A506628AB; Mon, 7 Feb 2005 21:14:31 +0000 (GMT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16903.55863.356308.420429@farnswood.snap.net.nz> Date: Tue, 08 Feb 2005 01:54:00 -0000 To: Andrew Cagney Cc: Bob Rossi , Jason Molenda , gdb@sources.redhat.com Subject: Event notification in MI (was Re: fullname descriptor with -break-list) In-Reply-To: <420787A3.2070605@gnu.org> References: <16902.30786.705993.121669@farnswood.snap.net.nz> <20050206210637.GB19609@white> <16902.45534.858929.941689@farnswood.snap.net.nz> <20050207134829.GA21985@white> <420787A3.2070605@gnu.org> X-SW-Source: 2005-02/txt/msg00032.txt.bz2 Andrew Cagney writes: > > >>-exec-run > >>^running > >>(gdb) > >>*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x080486e2",func="myprint",args=[{name="i",value="0"},{name="j",value="0"}],file="myprint.c",line="5"} ... > The way that message is generated is a massive kludge - so the > underlying code could do with a cleanup - separate the code determining > why the process stopped from the code printing the stop reason. I think I finally understand what you were saying in an earlier thread (Re: How does GDB/MI give the current frame - June 2004): AC> When the user does "up", "down", the debugger should generate a selected AC> CLI frame changed event (it currently doesn't). If the GUI so chooses, AC> it can track the users "selected" frame, by responding to these events. I guess that this output is not associated with a particular MI command but a change of state. In this way, the same output would be generated by a CLI command if it produced the same change of state (I was arguing that it shouldn't at the time), although presumably it would be only be turned on by selecting the MI interpreter. This complies with Richard Stallman's requirement that Emacs doesn't lose the GUD buffer. Previously I had in mind replacing each CLI command that I used with an MI equivalent "info break" -> -break-list, "info stack" -> -stack-list-frames etc and updating after every user command. This is probably less efficient and CLI commands would not always work. Currently, "*stopped" seems to be the only such event notification implemented in GNU GDB. Jason Molenda described a list of notifications that are currently used by Apple's version: JW> FWIW, here's the list of notification hooks we currently generate: JW> breakpoint_create, breakpoint_modify, breakpoint_delete, stack_changed, JW> frame_changed, thread_changed. It would be good to have these available to GNU GDB. If Apple can merge these changes in that would be ideal. Failing that I would like to try to implement them in GNU GDB (using observers?). This latter approach would take much longer, of course, and also make it harder to keep the Xcode and GNU gdb versions in sync. Nick