This is the mail archive of the 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.

On Sep 18, 2003, at 8:30 AM, wrote:


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
show auto-solib
&"show auto-solib\n"

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 "
~"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"}

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"

-interpreter-exec console next
~"41\t\tchar array[2][2] = { 'a', 'b', 'c'};\n"

The front-end fall out of step with gdb and no longer has relevant information.
However doing CLI without -interpreter-exec is good.

^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"}

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
*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 Ingham                         
Developer Tools
Apple Computer

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