From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14881 invoked by alias); 11 Sep 2003 03:11:15 -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 14874 invoked from network); 11 Sep 2003 03:11:12 -0000 Received: from unknown (HELO lakemtao01.cox.net) (68.1.17.244) by sources.redhat.com with SMTP; 11 Sep 2003 03:11:12 -0000 Received: from white ([68.9.191.65]) by lakemtao01.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20030911031111.FPKO29208.lakemtao01.cox.net@white>; Wed, 10 Sep 2003 23:11:11 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 19xHrU-0004lR-00; Wed, 10 Sep 2003 23:11:12 -0400 Date: Thu, 11 Sep 2003 03:11:00 -0000 From: Bob Rossi To: Elena Zannoni Cc: gdb@sources.redhat.com Subject: Re: vast numbers of unimplemented MI commands. Message-ID: <20030911031111.GG17937@white> Mail-Followup-To: Elena Zannoni , gdb@sources.redhat.com References: <20030911020429.GF17937@white> <16223.58420.108851.41512@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16223.58420.108851.41512@localhost.redhat.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-09/txt/msg00147.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. 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 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. 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? ... Bob Rossi On Wed, Sep 10, 2003 at 10:55:48PM -0400, Elena Zannoni wrote: > Bob Rossi writes: > > Hi, > > > > I just was looking through the MI commands. Many of them in mi-cmds.c > > are unimplemented. Is this how 6.0 will be released? or will most of > > them get implemented first? > > > > The set of MI commands was decided before there really was any GUI > using them. We thought it would be a reasonable set of commands that > would allow a GUI to do what it needed. We decided to implement them > as the need would arise. It turned out in reality that not all those > commands were necessary. > > > Also, how does eclipse interface with MI if so many commands are > > missing? For example, -file-list-exec-source-files returns all of the > > source files that the inferior is made up of. Does eclipse just not give > > the user this info, or would it parse the CLI output? > > > > I am not sure what Eclipse does in this case. You can look at the > debugger plugin code at http://www.eclipse.org/cdt. I suspect that > that information may come from some other part of the Eclipse IDE. > > > I am bringing this up because I plan on starting my own MI integration > > and ran into this problem. I would be willing to help implement any of > > these missing commands, but I was just wondering if there is any > > incentive on the GDB team to finish off the task. > > > > Realistically, not much else will go into 6.0, except bug fixes, since > 6.0 will happen in a week or so. There is always 6.1. > > elena > > > > Bob Rossi