Re: vast numbers of unimplemented MI commands.

Re: vast numbers of unimplemented MI commands.

[Jim Ingham]

Alain,

On Sep 19, 2003, at 7:50 AM, Alain Magloire wrote:

>
> [some lines deleted]
> ....
>
>> I don't think that is right.  You could always issue console commands
>> straight to the mi, THAT is the real way to cheat (and I agree that
>> should be closed off).  The console interpreter (and -interpreter-exec
>> console) fulfills a very useful purpose: satisfying folks who like a
>> console interface to gdb as well as the GUI.  We would probably get
>> assassinated right quick if we were to try to take this out of Xcode
>> (used to be Project Builder - another Marketing person earns their
>> salary!) .
>>
>> Note that we have had to fix up a few things in the MI as we have gone
>> along with Xcode, and most of those fixes are in the Apple sources not
>> in the main FSF repository.  We are short-staffed for what we need to
>
> And for the fixes ... thank you !!!
>
>> do here, which sort of explains why we haven't gotten to submitting  
>> our
>> sources back to the FSF - experience has shown that to be very time
>> consuming.  But you can get the Apple sources from the Apple Darwin
>> site, or from the opendarwin site.  If you are serious about using the
>> MI it might be worth your while to have a look here, since Xcode is  
>> the
>> only fairly mature GUI the uses the MI...
>>
>
> I disagree 8-).
> There are a few that uses MI and do a good job at it.

I don't mean to disparage any of the other projects that use MI.  When  
we converted PB to MI three years ago, we really were the only users  
(the project for which it was invented having perished ignominiously  
before I left RedHat...)

> This is not saying Xcode is not a great product of course 8-)
> I do not have a Mac to try it, but any URL handy with good snapshots?
> or just docs on Xcode ?

The developer pages are at:

http://developer.apple.com/tools/xcode/index.html

The debugger is by no means done, and we have been focusing more on  
high-level language features.  So for instance, we don't yet support  
Memory views, etc (which I am sure are more important to you at qnx...)  
  But some things like the variable formatters are pretty neat (and took  
a lot of work to make work reliably...)

>
> [...]
>
>> I don't understand this comment.  This is exactly what
>> -interpreter-exec console is for.  If the user issues this sort of
>> console command, you just echo back whatever it sends to your console
>> window.  You can also annotate if they do anything of other interest  
>> to
>> the GUI (proceeding the inferior, setting breakpoints, etc...)  Note
>> that to make parsing the output from gdb, I added a "console-quoted"
>> interpreter that sends stuff back in the cli pretty-printing, but the
>> output strings are packaged up in MI format.  So you get something
>> like:
>>
>> -interpreter-exec console-quoted "info func"
>> ~"All defined functions:\n"
>> ~"\nFile "
>> ~"/SourceCache/Csu/Csu-46/crt.c:\n"
>> ~"void _start(int, char **, char **);\n"
>> ~"static void _call_mod_init_funcs(void);\n"
>> ...
>> ^done,time={wallclock="1.83584",user="1.02000",system="0.11000",start= 
>> "1
>> 063903591.475599",end="1063903593.311440"}
>> (gdb)
>>
>>
>> This means that if the response from a command happens to start with
>> ^done or something like that, you won't get confused...
>>
>
> Yes this is the answer to our prayers.
> "-interpreter-exec console" does not do anything for us since we
> can not use it to sync the UI from the user input.
> However "-interpreter-exec console-quoted", at least, how you
> describe it is what we want.

One other thing to note is that the gdb Mac OS X native target is a  
true asychronous target - we run the ptrace waits in a separate thread  
(and the Mach exceptions handler, you really don't want to know...) so  
the event loop is always live.  This means that when the target is  
running, the GUI can ask gdb what it's state is (we made a -exec-status  
command for this) and get back "running" or "stopped".  So whenever it  
gets really confused, it can just do this.  Getting the async target to  
work was a royal pain in the neck, and there are still some residual  
problems, but for this purpose it is really handy!

>
>
>> I still have some cleanup to do on this, because there are various
>> places (like the show command) where the command ignores the uiout and
>> prints straight to gdbstdout (grrr....)  But this makes it pretty easy
>> to handle this sort of thing.
>>
>
> 8-)
>
>>
>
> [...]
>
>> This is just a hole in the interpreter-exec console implementation.   
>> We
>> tarted this up a bit on our end, so you get:
>>
>> -interpreter-exec console-quoted next
>> ^stepping
>> ^running
>> (gdb)
>> *stopped,time={wallclock="0.01305",user="0.00000",system="0.02000",sta 
>> rt
>> ="1063903739.568366",end="1063903739.581413"},reason="end-stepping-
>> range",thread-id="1"
>>
>
> Yes, Yes , Yes !
> Now __This__ is usefull.
>
>> I forget why the GUI guys wanted the ^stepping as well as the  
>> ^running,
>> for regularity it would probably be better to leave that out.  But  
>> with
>>
>
> I can guess:
> ^stepping and ^running are vital for the IDE to maintain its state
> without them "console-quoted" is as useless as "-interpreter-exec  
> console".
> There is a difference between "next" and "continue"(for the IDE) and
> the ^running is if the next statement is blocking, the IDE will know  
> that
> it is running.
>
>> this modification, it is very easy to keep the GUI in sync with the
>> CLI.  The Xcode console interpreter actually works pretty well, and
>> very seldom gets out of sync with the GUI.
>>
>
> In any case ... very nice improvements.
>
> [...]
>
>> This has not been our experience.  Xcode doesn't use any CLI commands,
>> provided you don't consider "-interpreter-exec" a console command.  It
>> took some work on our part to get this all going, but it is very
>> achievable.
>>
>
> Well then how do you deal with shared libraries ? How do you do
> deferred breakpoints? how do you load a shared library symbol ?
> How do you get the signal handlers? How do you set the handle for a  
> signal ?
> etc, etc  ...

For shared libraries we added the "future-break" command which will  
keep trying to set a breakpoint till it takes.  We actually tried to  
submit that a while ago, but there was no consensus whether this should  
be a separate command, the default behavior of break, or what.  We got  
distracted by some emergency, and this went no further.

We also send asychronous notifications of shared library loads so the  
GUI can present a table of the loaded shlibs.

We haven't had requests for a GUI for signal handling yet, when we do  
we will have to implement something...

>
> There are currently no MI counterparts ... at least in the FSF version.
> And the console prompt is a problem that "-interpreter-exec console"
> does not solve, .. but looking forward for "-interpreter-exec  
> console-quoted".
>

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: vast numbers of unimplemented MI commands.

[Andrew Cagney]

> For shared libraries we added the "future-break" command which will  keep trying to set a breakpoint till it takes.  We actually tried to  submit that a while ago, but there was no consensus whether this should  be a separate command, the default behavior of break, or what.  We got  distracted by some emergency, and this went no further.

That is simply not correct.  Tom Tromy pointed out a problem with the 
original change (that people would just use future-break) and Apple 
never responded.  Since then a proposal "fix break, not add 
future-break" has been posted:
http://sources.redhat.com/ml/gdb/2003-03/msg00158.html
and even you agreed.
http://sources.redhat.com/ml/gdb/2003-03/msg00217.html

Andrew

Re: vast numbers of unimplemented MI commands.

[Alain Magloire]

[some lines deleted]
....

> I don't think that is right.  You could always issue console commands  
> straight to the mi, THAT is the real way to cheat (and I agree that  
> should be closed off).  The console interpreter (and -interpreter-exec  
> console) fulfills a very useful purpose: satisfying folks who like a  
> console interface to gdb as well as the GUI.  We would probably get  
> assassinated right quick if we were to try to take this out of Xcode  
> (used to be Project Builder - another Marketing person earns their  
> salary!) .
> 
> Note that we have had to fix up a few things in the MI as we have gone  
> along with Xcode, and most of those fixes are in the Apple sources not  
> in the main FSF repository.  We are short-staffed for what we need to  

And for the fixes ... thank you !!!

> do here, which sort of explains why we haven't gotten to submitting our  
> sources back to the FSF - experience has shown that to be very time  
> consuming.  But you can get the Apple sources from the Apple Darwin  
> site, or from the opendarwin site.  If you are serious about using the  
> MI it might be worth your while to have a look here, since Xcode is the  
> only fairly mature GUI the uses the MI...
> 

I disagree 8-).
There are a few that uses MI and do a good job at it.
This is not saying Xcode is not a great product of course 8-)
I do not have a Mac to try it, but any URL handy with good snapshots?
or just docs on Xcode ?

[...]

> I don't understand this comment.  This is exactly what  
> -interpreter-exec console is for.  If the user issues this sort of  
> console command, you just echo back whatever it sends to your console  
> window.  You can also annotate if they do anything of other interest to  
> the GUI (proceeding the inferior, setting breakpoints, etc...)  Note  
> that to make parsing the output from gdb, I added a "console-quoted"  
> interpreter that sends stuff back in the cli pretty-printing, but the  
> output strings are packaged up in MI format.  So you get something  
> like:
> 
> -interpreter-exec console-quoted "info func"
> ~"All defined functions:\n"
> ~"\nFile "
> ~"/SourceCache/Csu/Csu-46/crt.c:\n"
> ~"void _start(int, char **, char **);\n"
> ~"static void _call_mod_init_funcs(void);\n"
> ...
> ^done,time={wallclock="1.83584",user="1.02000",system="0.11000",start="1 
> 063903591.475599",end="1063903593.311440"}
> (gdb)
> 
> 
> This means that if the response from a command happens to start with  
> ^done or something like that, you won't get confused...
> 

Yes this is the answer to our prayers.
"-interpreter-exec console" does not do anything for us since we
can not use it to sync the UI from the user input.
However "-interpreter-exec console-quoted", at least, how you
describe it is what we want.


> I still have some cleanup to do on this, because there are various  
> places (like the show command) where the command ignores the uiout and  
> prints straight to gdbstdout (grrr....)  But this makes it pretty easy  
> to handle this sort of thing.
> 

8-)

>

[...]

> This is just a hole in the interpreter-exec console implementation.  We  
> tarted this up a bit on our end, so you get:
> 
> -interpreter-exec console-quoted next
> ^stepping
> ^running
> (gdb)
> *stopped,time={wallclock="0.01305",user="0.00000",system="0.02000",start 
> ="1063903739.568366",end="1063903739.581413"},reason="end-stepping- 
> range",thread-id="1"
> 

Yes, Yes , Yes !
Now __This__ is usefull.

> I forget why the GUI guys wanted the ^stepping as well as the ^running,  
> for regularity it would probably be better to leave that out.  But with  
>

I can guess:
^stepping and ^running are vital for the IDE to maintain its state
without them "console-quoted" is as useless as "-interpreter-exec console".
There is a difference between "next" and "continue"(for the IDE) and 
the ^running is if the next statement is blocking, the IDE will know that
it is running.

> this modification, it is very easy to keep the GUI in sync with the  
> CLI.  The Xcode console interpreter actually works pretty well, and  
> very seldom gets out of sync with the GUI.
>

In any case ... very nice improvements.

[...]

> This has not been our experience.  Xcode doesn't use any CLI commands,  
> provided you don't consider "-interpreter-exec" a console command.  It  
> took some work on our part to get this all going, but it is very  
> achievable.
> 

Well then how do you deal with shared libraries ? How do you do
deferred breakpoints? how do you load a shared library symbol ?
How do you get the signal handlers? How do you set the handle for a signal ?
etc, etc  ...

There are currently no MI counterparts ... at least in the FSF version.
And the console prompt is a problem that "-interpreter-exec console"
does not solve, .. but looking forward for "-interpreter-exec console-quoted".

Re: vast numbers of unimplemented MI commands.

[Jim Ingham]

On Sep 18, 2003, at 8:30 AM, gdb-digest-help@sources.redhat.com wrote:

>
>
>>
>> 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.

I don't think that is right.  You could always issue console commands  
straight to the mi, THAT is the real way to cheat (and I agree that  
should be closed off).  The console interpreter (and -interpreter-exec  
console) fulfills a very useful purpose: satisfying folks who like a  
console interface to gdb as well as the GUI.  We would probably get  
assassinated right quick if we were to try to take this out of Xcode  
(used to be Project Builder - another Marketing person earns their  
salary!) .

Note that we have had to fix up a few things in the MI as we have gone  
along with Xcode, and most of those fixes are in the Apple sources not  
in the main FSF repository.  We are short-staffed for what we need to  
do here, which sort of explains why we haven't gotten to submitting our  
sources back to the FSF - experience has shown that to be very time  
consuming.  But you can get the Apple sources from the Apple Darwin  
site, or from the opendarwin site.  If you are serious about using the  
MI it might be worth your while to have a look here, since Xcode is the  
only fairly mature GUI the uses the MI...

>>
>
> 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).
>

I don't understand this comment.  This is exactly what  
-interpreter-exec console is for.  If the user issues this sort of  
console command, you just echo back whatever it sends to your console  
window.  You can also annotate if they do anything of other interest to  
the GUI (proceeding the inferior, setting breakpoints, etc...)  Note  
that to make parsing the output from gdb, I added a "console-quoted"  
interpreter that sends stuff back in the cli pretty-printing, but the  
output strings are packaged up in MI format.  So you get something  
like:

-interpreter-exec console-quoted "info func"
~"All defined functions:\n"
~"\nFile "
~"/SourceCache/Csu/Csu-46/crt.c:\n"
~"void _start(int, char **, char **);\n"
~"static void _call_mod_init_funcs(void);\n"
...
^done,time={wallclock="1.83584",user="1.02000",system="0.11000",start="1 
063903591.475599",end="1063903593.311440"}
(gdb)


This means that if the response from a command happens to start with  
^done or something like that, you won't get confused...

I still have some cleanup to do on this, because there are various  
places (like the show command) where the command ignores the uiout and  
prints straight to gdbstdout (grrr....)  But this makes it pretty easy  
to handle this sort of thing.

>
> - 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.

This is just a hole in the interpreter-exec console implementation.  We  
tarted this up a bit on our end, so you get:

-interpreter-exec console-quoted next
^stepping
^running
(gdb)
*stopped,time={wallclock="0.01305",user="0.00000",system="0.02000",start 
="1063903739.568366",end="1063903739.581413"},reason="end-stepping- 
range",thread-id="1"

I forget why the GUI guys wanted the ^stepping as well as the ^running,  
for regularity it would probably be better to leave that out.  But with  
this modification, it is very easy to keep the GUI in sync with the  
CLI.  The Xcode console interpreter actually works pretty well, and  
very seldom gets out of sync with the GUI.

>
>> 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.

This has not been our experience.  Xcode doesn't use any CLI commands,  
provided you don't consider "-interpreter-exec" a console command.  It  
took some work on our part to get this all going, but it is very  
achievable.

>>
>> 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.

We have had pretty good success with the MI so far...

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: vast numbers of unimplemented MI commands.

[Alain Magloire]

> 
> 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.

Re: vast numbers of unimplemented MI commands.

[Joel Brobecker]

> Somebody like you for instance (who understands the needs of GDB
> frontends because he's developping one) who also invests time into
> making GDB/MI better. See for instance one of the commands that
> our GVD (our graphical front-end) needed: What we did was simply propose
> a new command, discussed it, and then implemented it.

And I forgot to say: it may seem that working both on your frontend and
GDB is increase your amount of work. But on the crontrary, I think this
approach is going to save you some time in the long run. Based on the
GVD experience, the less CLI output you have to parse, the better off
you'll be.

-- 
Joel

Re: vast numbers of unimplemented MI commands.

[Joel Brobecker]

> What is the best solution? ...

Somebody like you for instance (who understands the needs of GDB
frontends because he's developping one) who also invests time into
making GDB/MI better. See for instance one of the commands that
our GVD (our graphical front-end) needed: What we did was simply propose
a new command, discussed it, and then implemented it.

It's true that our example is a bit biased because the alternative way
is a real pain compared to what the new command provides, so one could
say there was no real work-around to the problem. But still, this is how
things moved forward for us.

Could it work for you?

My suggestion would be that you implement all the functions you need,
and also make suggestions when something is missing... I think the
current speed of MI development is partly because few of its users
send any suggestion or complaint - and the fact that one can "work
around" any missing command doesn't help. And even if somebody sends
suggestions, I'm not certain anybody will stand up and implement the
suggestion unless he has any incentive to do so: And my guess is that
the only people who could feel this incentive are the developpers
working on a GDB frontend. Again, people like you.

-- 
Joel

Re: vast numbers of unimplemented MI commands.

[Andrew Cagney]

> 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.
>  > 
> 
> since
> 6.0 will happen in a week or so.

Hopefully less than that.

Andrew

Re: vast numbers of unimplemented MI commands.

[Bob Rossi]

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

Re: vast numbers of unimplemented MI commands.

[Elena Zannoni]

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

vast numbers of unimplemented MI commands.

[Bob Rossi]

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?

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 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.

Bob Rossi