Re: [5.1/mi] Enable MI interface

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

Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Jim Ingham]

Andrew & Fernando,

Okay, here are Rab's comments about the proposed change to the MI 
interface (Rab Hagy (rhagy@apple.com) is the fellow responsible for the 
Project Builder side of debugging for Apple's IDE.):

> 1) The delimiters for a list should be different from those for a tuple.
> The output of MI is, basically, a property list. Property lists have 
> been around for a long time and they have different delimiters for 
> tuples and lists.
>
> The current situation, in which the same delimiters are used for both 
> lists and tuples, results in stream of MI output which is difficult to 
> inspect "by eye". The parser is a bit more complex than it needs to be 
> because it has to handle the overloading of '{'. As a result, the data 
> structures used to represent a VALUE is not a clean as they could be 
> either.
>
> And, I mean this in the nicest way possible, this oversight sticks out 
> like a sore thumb... when I wrote the special-cases in the parser to 
> deal with this obvious error in the grammar, I wondered if MI was 
> really up to snuff.
>
> 2) '[' and ']' are the correct delimiters
> Adding these characters to the grammar does not complicate the parsing 
> of MI output. These are the obvious characters to be used as the 
> delimiters for a list.
>
> 3) ``[bp="1",bp="2",bp="4"]'' is incorrect
> I don't think this example is allowed by the proposed grammar. It 
> should be one of:
> 	bps=["1", "2", "4"]
> 	[{bp="1"}, {bp="2"}, {bp="4"}]
>
> -rab

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

Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Fernando Nasser]

I rest my case :-)

Jim Ingham wrote:
> 
> Andrew & Fernando,
> 
> Okay, here are Rab's comments about the proposed change to the MI
> interface (Rab Hagy (rhagy@apple.com) is the fellow responsible for the
> Project Builder side of debugging for Apple's IDE.):
> 
> > 1) The delimiters for a list should be different from those for a tuple.
> > The output of MI is, basically, a property list. Property lists have
> > been around for a long time and they have different delimiters for
> > tuples and lists.
> >
> > The current situation, in which the same delimiters are used for both
> > lists and tuples, results in stream of MI output which is difficult to
> > inspect "by eye". The parser is a bit more complex than it needs to be
> > because it has to handle the overloading of '{'. As a result, the data
> > structures used to represent a VALUE is not a clean as they could be
> > either.
> >
> > And, I mean this in the nicest way possible, this oversight sticks out
> > like a sore thumb... when I wrote the special-cases in the parser to
> > deal with this obvious error in the grammar, I wondered if MI was
> > really up to snuff.
> >
> > 2) '[' and ']' are the correct delimiters
> > Adding these characters to the grammar does not complicate the parsing
> > of MI output. These are the obvious characters to be used as the
> > delimiters for a list.
> >
> > 3) ``[bp="1",bp="2",bp="4"]'' is incorrect
> > I don't think this example is allowed by the proposed grammar. It
> > should be one of:
> >       bps=["1", "2", "4"]
> >       [{bp="1"}, {bp="2"}, {bp="4"}]
> >
> > -rab
> 
> Jim
> --
> Jim Ingham                                   jingham@apple.com
> Developer Tools - gdb
> Apple Computer

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: gdb Digest 5 Mar 2001 20:42:12 -0000 Issue 473

[Jim Ingham]

Andrew,

Both Project Builder and Insight offer a traditional GDB console as well 
as the GUI interface to gdb.  In the case of Insight, the thought was 
that once the GUI provided ALL the access that you could need to gdb's 
functionality it would go away.  In the case of PB, we have pretty 
strong feedback from our users that they REALLY like having the console 
there...  So we will need to provide some way to run console commands, 
WHILE using the MI as the communications channel between gdb & PB.  And 
the use of query is at present a problem which we still need to solve.

So while I agree that the design of the MI itself, and of the libgdb 
interface by extension - should avoid this kind of callback, I at least 
need to think some more about how to support the CLI over MI mode for 
the near future.  Tcl had the notion of service modes in its 
interpreter, so that you could modally re-enter the event loop looking 
for a particular bit of information, but not handling other types.  This 
was needed, for instance, to do things like wait for Window creation in 
Tk before you went on to do something with the window...  Maybe we could 
use this sort of notion to post & wait on the input channel without 
losing the local execution context?

Jim

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

>
> From conversations, I believe that the current thinking is that MI
> operations should be largely self contained - they should not involve
> things like call-backs.
>
> Comments?
>
> 	Andrew

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

[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?