[5.1/mi] Enable MI interface

[5.1/mi] Enable MI interface

[Andrew Cagney]

Hello,

A 5.1 release criteria is enabling the MI interface.

Once my other MI questions get resolved, the biggest problem I can see
with this is with the MI testsuite.  Once MI is enabled the testsuite
will kick in and, most likely, some targets will have additional
failures.

If anyone can see any problems with this, please start rasing them now
:-)  The change required to enable the MI is trivial.  The consequences
may not be :-)

For reference, the testsuite output on a BSD UNIX system looks like:

Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-basics.exp ...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-break.exp ...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-console.exp ...
FAIL: gdb.mi/mi-console.exp: Hello message (timeout)
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-disassemble.exp
...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-eval.exp ...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-hack-cli.exp ...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-read-memory.exp
...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-regs.exp ...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-return.exp ...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-simplerun.exp ...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-stack.exp ...
FAIL: gdb.mi/mi-stack.exp: stack args listing 0
FAIL: gdb.mi/mi-stack.exp: stack args listing 1
FAIL: gdb.mi/mi-stack.exp: stack info-depth
FAIL: gdb.mi/mi-stack.exp: stack info-depth 99
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-stepi.exp ...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-until.exp ...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-var-block.exp ...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-var-child.exp ...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-var-cmd.exp ...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-var-display.exp
...
Running /home/scratch/GDB/src/gdb/testsuite/gdb.mi/mi-watch.exp ...
FAIL: gdb.mi/mi-watch.exp: wp out of scope (2)

                === gdb Summary ===

# of expected passes            486
# of unexpected failures        6
# of expected failures          14

Hmm, thinking about it, 500 additional tests is pretty impressive!  Well
done Elena and Fernando!

	Andrew

Re: [5.1/mi] Enable MI interface

[Eli Zaretskii]

> Date: Sun, 04 Mar 2001 21:29:44 -0500
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> A 5.1 release criteria is enabling the MI interface.
> 
> Once my other MI questions get resolved, the biggest problem I can see
> with this is with the MI testsuite.  Once MI is enabled the testsuite
> will kick in and, most likely, some targets will have additional
> failures.
> 
> If anyone can see any problems with this, please start rasing them now
> :-)  The change required to enable the MI is trivial.  The consequences
> may not be :-)

Bother.  Can you, or someone else, please describe in a few words what
does "enable the MI interface" mean, in practical terms, for a port
such as the DJGPP port?

Re: [5.1/mi] Enable MI interface

[Andrew Cagney]

Eli Zaretskii wrote:
> 
> > Date: Sun, 04 Mar 2001 21:29:44 -0500
> > From: Andrew Cagney <ac131313@cygnus.com>
> >
> > A 5.1 release criteria is enabling the MI interface.
> >
> > Once my other MI questions get resolved, the biggest problem I can see
> > with this is with the MI testsuite.  Once MI is enabled the testsuite
> > will kick in and, most likely, some targets will have additional
> > failures.
> >
> > If anyone can see any problems with this, please start rasing them now
> > :-)  The change required to enable the MI is trivial.  The consequences
> > may not be :-)
> 
> Bother.  Can you, or someone else, please describe in a few words what
> does "enable the MI interface" mean, in practical terms, for a port
> such as the DJGPP port?

Nothing (yes, ok famous last words :-).

At present the gdb/mi directory isn't built.  Enabling the MI would mean
building that directory and linking it into GDB.  For a DJGPP user, this
just means that GDB gained a few kilos.

The big change really occured ~2 months ago when ui-out became the
normal mechanism to use when outputing something.  Since the old
*_printf() interface remains, no one noticed (1) :-)

enjoy,
	Andrew

(1) Almost no one.  There were a few bugs where the output changed
slightly and where found the output was fixed.

Re: [5.1/mi] Enable MI interface

[Eli Zaretskii]

On Mon, 5 Mar 2001, Andrew Cagney wrote:

> > Bother.  Can you, or someone else, please describe in a few words what
> > does "enable the MI interface" mean, in practical terms, for a port
> > such as the DJGPP port?
> 
> Nothing (yes, ok famous last words :-).
> 
> At present the gdb/mi directory isn't built.  Enabling the MI would mean
> building that directory and linking it into GDB.

So, at the very least, I should review the code in gdb/mi and see that
it compiles and doesn't do anything that shouldn't be done on
DOS/Windows.

> For a DJGPP user, this just means that GDB gained a few kilos.

That's actually not so good: the current build already overflows the
COFF limit of 64K lines in the debug info, albeit by a small margin;
adding more code will make things much worse...

Which reminds me: is there any reasonable way to prevent GDB from
linking in all those *read.c modules DJGPP users will never need?
I've never understood why do we have to pull into GDB things like
mipsread, os9kread, mdebugread, and others, which will never be used.
(Note that this setup predates multi-arch, so there's got to be some
reason which doesn't involve multi-arch.)  If I don't link those in, I
might save a significant part of memory footprint, and prevent the
line number overflow while at that.

> The big change really occured ~2 months ago when ui-out became the
> normal mechanism to use when outputing something.

Well, this already works for me (I'm using a month-old snapshot).

Re: [5.1/mi] Enable MI interface

[Andrew Cagney]

Eli Zaretskii wrote:

> So, at the very least, I should review the code in gdb/mi and see that
> it compiles and doesn't do anything that shouldn't be done on
> DOS/Windows.

Yes.  It should compile.

The question, does MI make sense under DJGPP should probably also be
considered.  The current convention is to include everything.  It isn't
for us to decide what someone should or shouldn't use.

> Which reminds me: is there any reasonable way to prevent GDB from
> linking in all those *read.c modules DJGPP users will never need?
> I've never understood why do we have to pull into GDB things like
> mipsread, os9kread, mdebugread, and others, which will never be used.
> (Note that this setup predates multi-arch, so there's got to be some
> reason which doesn't involve multi-arch.)  If I don't link those in, I
> might save a significant part of memory footprint, and prevent the
> line number overflow while at that.

At present no. Because the same GDB can be used to debug both native and
remote targets, support for all possible debuging formats is always
included.  Yes, some of them don't make much sense.

The same issue arises with the simulator targets.  Native GDB's include
simulators even though some people think they are excess baggage.

I think a good time to review these conventions is going to be when
--with-targets=..,.. starts working.  At that point, GDB would be able
to contain everything - gaining more than just a few kilos :-)  It would
probably make sense to only include the debug formats applicable to the
selected group of targets.

	Andrew

Re: [5.1/mi] Enable MI interface

[Eli Zaretskii]

> Date: Tue, 06 Mar 2001 11:45:24 -0500
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> The question, does MI make sense under DJGPP should probably also be
> considered.

How is DJGPP different from other ports in this aspect?

As far as I understand, MI is just another interface to GDB's core
functionality, specifically tailored to programs (as opposed to CLI
which is tailored for humans).  If it's considered a Good Thing to
have this on other platforms, I don't see why it won't make sense with
DJGPP.

Am I missing something?

Re: [5.1/mi] Enable MI interface

[Jim Ingham]

Eli,

On Monday, March 5, 2001, at 12:42 PM, gdb-digest-
help@sources.redhat.com wrote:

>
> Bother.  Can you, or someone else, please describe in a few words what
> does "enable the MI interface" mean, in practical terms, for a port
> such as the DJGPP port?

Should mean not too much.  If the ui_out stuff works on your host 
platform, then you should pretty much get the MI for free.  It is 
another command set for gdb, and a particular ui_out that formats the 
output to these commands in a more deterministicly parseable way than 
raw gdb console output.

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

Re: [5.1/mi] Enable MI interface

[Eli Zaretskii]

On Mon, 5 Mar 2001, Jim Ingham wrote:

> Should mean not too much.  If the ui_out stuff works on your host 
> platform, then you should pretty much get the MI for free.  It is 
> another command set for gdb, and a particular ui_out that formats the 
> output to these commands in a more deterministicly parseable way than 
> raw gdb console output.

IIRC MI is an interface between GDB and what/whoever is using GDB,
right?  If so, how, if at all, does it come into play in the normal
DJGPP usage where the user types command into GDB's CLI interface?
Does something convert these commands into MI before passing them to
GDB?

Or does the addition of MI simply mean that there's another command
language available to the user, which they can use as they see fit?
That is, unless the users actually type some MI commands, the MI code
will not spring into action at all?

Or am I missing the point entirely?

Re: [5.1/mi] Enable MI interface

[Andrew Cagney]

Eli Zaretskii wrote:
> 
> On Mon, 5 Mar 2001, Jim Ingham wrote:
> 
> > Should mean not too much.  If the ui_out stuff works on your host
> > platform, then you should pretty much get the MI for free.  It is
> > another command set for gdb, and a particular ui_out that formats the
> > output to these commands in a more deterministicly parseable way than
> > raw gdb console output.
> 
> IIRC MI is an interface between GDB and what/whoever is using GDB,
> right?  If so, how, if at all, does it come into play in the normal
> DJGPP usage where the user types command into GDB's CLI interface?
> Does something convert these commands into MI before passing them to
> GDB?

Yes.  One day, GDB will look like:

	CLI ->	libgdb  <- MI
	       core-gdb

at present it looks more like:

	corCe-gLdbI <- liMbgIb
	core-gdb+CLI <- libgdb+MI

However, it is still possible to build with/without out the MI.

> Or does the addition of MI simply mean that there's another command
> language available to the user, which they can use as they see fit?
> That is, unless the users actually type some MI commands, the MI code
> will not spring into action at all?

Unless the user enters:

	DOS>  gdb -i mi

MI will do nothing.

	Andrew