This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: vast numbers of unimplemented MI commands.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]