From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22895 invoked by alias); 15 Aug 2005 02:15:56 -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 22554 invoked by uid 22791); 15 Aug 2005 02:15:48 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 15 Aug 2005 02:15:48 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1E4UVu-0005W3-9D; Sun, 14 Aug 2005 22:15:46 -0400 Date: Mon, 15 Aug 2005 04:26:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: MI output during program execution Message-ID: <20050815021546.GA20931@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com References: <17151.52148.262754.334426@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17151.52148.262754.334426@farnswood.snap.net.nz> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-08/txt/msg00171.txt.bz2 On Mon, Aug 15, 2005 at 10:54:44AM +1200, Nick Roberts wrote: > > I've read most of the discussion through the archives. I find the idea of > notifying the frontend about all changes of state a laudable goal but > currently too difficult (for me). However, I would still like GDB to > convey to the frontend when the inferior is running. Jim's point about the > "define" command shoots down the patch that I sent earlier so I would like to > suggest another approach. I would like to take the "^running" and "*stopped" > tokens out of mi-main.c and put them in infrun.c where annotate_starting and > annotate_stopped are respectively called. This seems more in line with the > idea of notification and works when I test it natively on GNU/Linux. I am > sure that it will fail somewhere else (remote targets?) otherwise this > approach would have surely been used in the first place. > > With this method user-defined commands work as for simple GDB commands. CLI > commands don't give full MI output but information like the current line can > be obtained by polling with -stack-info-frame. > > -exec-next > ^running > (gdb) > *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x080484ef",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff794"}],file="myprog.c",fullname="/home/nick/myprog.c",line="46"} > (gdb) > n > &"n\n" > ^running > (gdb) > ~"47\t int n1=7, n2=8, n3=9;\n" > *stopped > ^done > (gdb) > > Using strcmp (interpreter_p, "mi") and not strncmp (interpreter_p, "mi", 2) > means that this should only change behaviour for the current mi level. Checking the name of the MI interpreter seems inelegant. It'll break this when we transition from MI2 to MI3 as the stable version for instance. Maybe there's a way to make mi_version usable outside of mi/*. Forcing this to raw_stdout is also not OK, since my whole point was to pass this information to the interpreter so that it can distribute it to clients appropriately - they may not be on stdout. I realize that's what the MI layer previously did, but I don't get a good taste in my mouth from bypassing the MI output layer this way. The hooks we were talking about were primarily for things like the breakpoint list and thread list. The ^running response is touchier. ^running is a result record, not an async record. It has to be the result of a command. Bob's our expert on this, but I'd think that this change could break the grammar. There's probably a way to get this to happen when the resulting prompt does not signify that another command may be accepted now. Certainly it makes verifying from the source that we obey the grammar much more difficult, by moving bits of the MI implementation into infrun. That's enough reason for it not to have been done this way in the first place - it's harder to maintain. Also, Bob said he was willing to work on doing this correctly. -- Daniel Jacobowitz CodeSourcery, LLC