From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27531 invoked by alias); 18 Sep 2003 15:30:02 -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 27524 invoked from network); 18 Sep 2003 15:30:01 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 18 Sep 2003 15:30:01 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id LAA27384 for ; Thu, 18 Sep 2003 11:28:43 -0400 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id LAA12429 for gdb@sources.redhat.com; Thu, 18 Sep 2003 11:30:01 -0400 Message-Id: <200309181530.LAA12429@smtp.ott.qnx.com> Subject: Re: vast numbers of unimplemented MI commands. To: bob@brasko.net (Bob Rossi) Date: Thu, 18 Sep 2003 15:30:00 -0000 From: "Alain Magloire" Cc: ezannoni@redhat.com (Elena Zannoni), gdb@sources.redhat.com In-Reply-To: <20030911031111.GG17937@white> from "Bob Rossi" at Sep 10, 2003 11:11:12 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00222.txt.bz2 > > Hi, > > I guess this seems ok, I just hate to see stuff like this. > > But if you can come up with a clean Interface(set of methods) of > what you need we could work things and put it in the CDI and implement > it in the GDB/MI plugin. The annoying thing is that GDB/MI does not > have any "mi" command for this, so we will have to send "cli" command > and do weird parsing on the output. > > from the eclipse mailing lists. Seeing this makes me think that the > whole community is not understanding that we need to have clean > interfaces between GDB and the front ends. > Amen to that!! > Developers that find a "missing hole" in GDB, don't seem to have the > desire to fix the hole when they can easily find a work around. > IMO, most developers don't have enough time to fix there own > front end and then go fix the debugger there integrating with. I hear you !!! 8-) > I think GDB should support a proper MI interface for front ends, and > thats the only way front ends should be able to communicate with it. > Adding the -interpreter console was probably the main cause in allowing > front ends to cheat there way past the MI interface. > Agreed, but not for the same reasons. We do not use the "-interpreter-exec console" because it turns out to be useless. The first attempt was to satisfy the CLI users within the IDE, so a prompt was given. But the problem is to synchronize the IDE, let see a scenario, the "show": - scenario 1 (show): # gdb -i mi hello ... (gdb) show auto-solib &"show auto-solib\n" ^done,value="on" (gdb) The problem here, and with many other commands, is that the information is return in MI jargon only, so the user will not see it. To do this correctly we would need a cli interpreter that will pretty print the output of any commands(no fun job, knowin the annoying cli syntax of gdb). - scenario 2 (show/next): The problem is reverse when doing -interpreter-exec, the information not is not in MI, this is illustrate when doing a "next" (gdb) -interpreter-exec console next ~"41\t\tchar array[2][2] = { 'a', 'b', 'c'};\n" ^done (gdb) The front-end fall out of step with gdb and no longer has relevant information. However doing CLI without -interpreter-exec is good. (gdb) next &"next\n" ^done,reason="end-stepping-range",thread-id="0",frame={addr="0x0804846e",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbfffeb54"}],file="hello.c",line="40"} (gdb) The front-end can keep up. > The problem is, every *real* world front end to GDB is doomed to end up > using a mix of MI commands and CLI commands. If GDB is ever released > in such a way that the CLI output is changed, all existing front ends > will break. Including the ones that use MI. > > What is the best solution? ... > Good question. Although I like to complain 8-) The move toward MI is a good one, it is much cleaner, kudos to gdb folks.