[proposal/testsuite] require build == host

[proposal/testsuite] require build == host

[Michael Chastain]

I'm working on a test script for the 'edit' command.  In order to test
the 'edit' command, the test script has to manage files on the host
machine (where gdb is running), not the build machine (where dejagnu is
running).

A recapitulation:

  build    runs dejagnu and the *.exp scripts
  host     runs gcc, as, ld, and gdb
  target   runs the test program such as "callfuncs" or "structs2"

I started looking at how other gdb test scripts work in a configuration
where build and host are different machines, and, well, they don't.
There are about a dozen scripts that compile test files with header
files, and except for list.exp, none of them download their *.h files to
the host machine.  gcore.exp manipulates files that gdb creates on the
host machine.  It needs to "remote upload" the files that gdb creates
back to the build machine, but it doesn't.  And so on.

Of course the test suite supports a target machine which is separate
from the build/host machine.  That is not at issue.

I don't think anyone actually uses a configuration with separate build
and host.  So I propose this patch to document that the gdb test suite
requires that build and host be the same machine.

I'll give this proposal a week for discussion.  I'm hoping that the
discussion goes "you're right, build-cross-host is silly and
unnecessary, just drop it already", but someone may have a good reason
for wanting it.

Testing: I built gdbint.texinfo with makeinfo 4.7 to check the syntax.
But that's not really important yet.  This is about the proposal,
not about the specific patch.

Comments?

Michael C

2004-07-24  Michael Chastain  <mec.gnu@mindspring.com>

	* gdbint.texinfo (Testsuite): Document that build and host
	must be the same machine.

Index: gdbint.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdbint.texinfo,v
retrieving revision 1.214
diff -c -3 -p -r1.214 gdbint.texinfo
*** gdbint.texinfo	1 Jul 2004 20:25:54 -0000	1.214
--- gdbint.texinfo	25 Jul 2004 00:01:08 -0000
*************** difficult to test, such as code that han
*** 6315,6320 ****
--- 6315,6325 ----
  in particular versions of compilers, and it's OK not to try to write
  tests for all of those.
  
+ DejaGNU supports separate build, host, and target machines.  However,
+ the @value{GDBN} testsuite requires that the host machine be the
+ same as the build machine.  This requirement simplifies the writing
+ of test files.
+ 
  @section Testsuite Organization
  
  @cindex test suite organization

Re: [proposal/testsuite] require build == host

[Felix Lee]

mec.gnu@mindspring.com (Michael Chastain):
> I don't think anyone actually uses a configuration with separate build
> and host.  So I propose this patch to document that the gdb test suite
> requires that build and host be the same machine.

hm.  gdb runs on more systems than expect does, and my feeling at
the moment is that it's sometimes easier to do build!=host
testing than it is to get expect running, like on weird embedded
linux devices.

not that I particularly like the testsuite complications added by
build!=host, but I don't know a better alternative yet.
--

Re: [proposal/testsuite] require build == host

[Daniel Jacobowitz]

On Sat, Jul 24, 2004 at 06:18:16PM -0700, Felix Lee wrote:
> mec.gnu@mindspring.com (Michael Chastain):
> > I don't think anyone actually uses a configuration with separate build
> > and host.  So I propose this patch to document that the gdb test suite
> > requires that build and host be the same machine.
> 
> hm.  gdb runs on more systems than expect does, and my feeling at
> the moment is that it's sometimes easier to do build!=host
> testing than it is to get expect running, like on weird embedded
> linux devices.
> 
> not that I particularly like the testsuite complications added by
> build!=host, but I don't know a better alternative yet.

Have you ever actually needed to do this?

When I tested GDB on embedded Linux devices, expect was not the issue. 
Expect is easy if you have enough RAM footprint to fit a GDB binary!

Also, what is a host on which GDB works but expect does not?

-- 
Daniel Jacobowitz

Re: [proposal/testsuite] require build == host

[Eli Zaretskii]

> Date: Sat, 24 Jul 2004 20:03:44 -0400 (EDT)
> From: mec.gnu@mindspring.com (Michael Chastain)
> 
> 2004-07-24  Michael Chastain  <mec.gnu@mindspring.com>
> 
> 	* gdbint.texinfo (Testsuite): Document that build and host
> 	must be the same machine.

I don't have an opinion about the issue, but the patch is okay with
me, provided that we agree to the requirement itself.

Perhaps this paragraph should be indexed, though: it sounds important
enough to warrant that.

Re: [proposal/testsuite] require build == host

[Felix Lee]

Daniel Jacobowitz <drow@false.org>:
> Also, what is a host on which GDB works but expect does not?

I remember running build!=host tests in some situations, but I
don't remember enough detail to demonstrate that it was really
necessary.  at the moment I'm mostly using retrograde reasoning:
the build!=host machinery is nontrivial, and it seems unlikely
that people would go to all that trouble if it were easy to just
get build==host working.

the issue isn't memory footprint, it's stuff like OS environment.
one thing that comes to mind: expect won't work if you don't have
ptys, but gdb works fine without ptys.  also, BeOS apparently has
a weird select() call that's hard to work with.

I think most of the build!=host machinery was invented in the
early days of cygwin testing.  it isn't necessary for cygwin now,
but it might be needed elsewhere.
--

Re: [proposal/testsuite] require build == host

[Michael Chastain]

Felix Lee <felix.1@canids.net> wrote:
lee> I remember running build!=host tests in some situations, but I
lee> don't remember enough detail to demonstrate that it was really
lee> necessary.

I won't say "show that there's no other way to get the same effect".
Because when one is trying to put a testbed together from several
components, it's much easier when more of the components are more
flexible.

If you've used build != host in the past, that's valid.

My question is: how far in the past?  Because it seems like
everything these days is gdb remote protocol.

lee> the issue isn't memory footprint, it's stuff like OS environment.
lee> one thing that comes to mind: expect won't work if you don't have
lee> ptys, but gdb works fine without ptys.  also, BeOS apparently has
lee> a weird select() call that's hard to work with.

If build != host, then the host does not have to run expect.
But the host does have to run some kind of network server
like telnet/ftp or rlogin/rcp (or kermit or tip or ...)

It's a tradeoff.  The situation right now is that there are 1-2 dozen
scripts which do not work in a build != host environment, and they've
been that way for several years.  I can spend time fixing these and
actually running some build != host test runs.  Or we can change the
policy so that build != host is not supported.

Hmmm, I just checked Dan Kegel's crosstool FAQ, and he wrote a
section on build != host testing for gcc, last revised
2004-01-04.  This argues against removing build != host from gdb.

Michael C

Re: [proposal/testsuite] require build == host

[Andrew Cagney]

What do the dejagnu maintainers have to say about the feature?  I can on 
the one hand see it being abandoned while on the other hand being used 
for something like parallel testing?

As for a system that would/should use this - djgpp.

Andrew

Re: [proposal/testsuite] require build == host

[Michael Chastain]

ac> What do the dejagnu maintainers have to say about the feature?

I haven't asked, but it's a supported feature of dejagnu and I'm
willing to accept that they will keep on supporting it.

Dan Kegel is at least one user of dejagnu who uses build != host
with gcc.  He wrote a whole section in his cross-gcc faq about it.
People are testing gcc with dejagnu using build != host,
so it would be good if gdb testing worked in the same environment.

ac> As for a system that would/should use this - djgpp.

You got me there.  It's been a while since I used windows,
but I suspect that windows has telnet/ftp servers.

Eli, is it possible to ftp into a windows box and upload and
download files?  More important, is it possible to telnet into
a windows box and run a command-line interpreter?

It looks like I should go with Plan B: file PR's against the
test scripts that don't work on build != host, and eventually
fix them.

Michael C

Re: [proposal/testsuite] require build == host

[Eli Zaretskii]

> Date: Mon, 26 Jul 2004 20:52:26 -0400
> From: Michael Chastain <mec.gnu@mindspring.com>
> 
> ac> As for a system that would/should use this - djgpp.
> 
> You got me there.  It's been a while since I used windows,
> but I suspect that windows has telnet/ftp servers.

(Btw, DJGPP produces DOS programs, not Windows programs.  These
programs do run on Windows, but Windows treats them as DOS
executables.)

> Eli, is it possible to ftp into a windows box and upload and
> download files?  More important, is it possible to telnet into
> a windows box and run a command-line interpreter?

It is possible to do that on Windows XP (perhaps after enabling some
service that is off by default, I don't remember).

Re: [proposal/testsuite] require build == host

[Felix Lee]

Michael Chastain <mec.gnu@mindspring.com>:
> If you've used build != host in the past, that's valid.
> My question is: how far in the past?  Because it seems like
> everything these days is gdb remote protocol.

can't remember last time I did it, this stuff never stays in my
mind long.  but friend says they still do build!=host testing at
TiVo.

> If build != host, then the host does not have to run expect.
> But the host does have to run some kind of network server
> like telnet/ftp or rlogin/rcp (or kermit or tip or ...)

yeah, I suspect whatever problems expect has could be fixed, any
type of network loopback could be used instead of the pty code.
it seems to be a nontrivial amount of work though.

> It's a tradeoff.  The situation right now is that there are 1-2 dozen
> scripts which do not work in a build != host environment, and they've
> been that way for several years.  I can spend time fixing these and
> actually running some build != host test runs.  Or we can change the
> policy so that build != host is not supported.

or those specific scripts could just yield unsupported when
build!=host.
--

Re: [proposal/testsuite] require build == host

[Andrew Cagney]

> ac> What do the dejagnu maintainers have to say about the feature?
> 
> I haven't asked, but it's a supported feature of dejagnu and I'm
> willing to accept that they will keep on supporting it.

It would be useful, just so that we know where they are going.

> Dan Kegel is at least one user of dejagnu who uses build != host
> with gcc.  He wrote a whole section in his cross-gcc faq about it.
> People are testing gcc with dejagnu using build != host,
> so it would be good if gdb testing worked in the same environment.
> 
> ac> As for a system that would/should use this - djgpp.
> 
> You got me there.  It's been a while since I used windows,
> but I suspect that windows has telnet/ftp servers.
> 
> Eli, is it possible to ftp into a windows box and upload and
> download files?  More important, is it possible to telnet into
> a windows box and run a command-line interpreter?

This is how the original cygwin testing was done - at a dos prompt.

> It looks like I should go with Plan B: file PR's against the
> test scripts that don't work on build != host, and eventually
> fix them.

For the moment, lets stick with the status quo.  Tests are required to 
work host==build.  Having a test work host!=build is an added bonus, but 
not a requrement.  We can hardly enforce host!=build when there's no way 
to test it and the return on investment is marginal.

Andrew

Re: [proposal/testsuite] require build == host

[Christopher Faylor]

On Tue, Jul 27, 2004 at 11:14:20AM -0400, Andrew Cagney wrote:
>>Eli, is it possible to ftp into a windows box and upload and download
>>files?  More important, is it possible to telnet into a windows box and
>>run a command-line interpreter?
>
>This is how the original cygwin testing was done - at a dos prompt.

Right.  And the test suite shennanigans necessary to support this were
truly ugly and, for some tests, only worked randomly.

>>It looks like I should go with Plan B: file PR's against the test
>>scripts that don't work on build != host, and eventually fix them.
>
>For the moment, lets stick with the status quo.  Tests are required to
>work host==build.  Having a test work host!=build is an added bonus,
>but not a requrement.  We can hardly enforce host!=build when there's
>no way to test it and the return on investment is marginal.

FWIW, I agree.

cgf

Re: [proposal/testsuite] require build == host

[Michael Chastain]

ac> It would be useful, just so that we know where they are going.

I talked to Rob Savoye a month or two ago, and basically
Dejagnu is mature at this point.  I don't think it's going to
add or drop major features.

ac> For the moment, lets stick with the status quo.  Tests are required to 
ac> work host==build.  Having a test work host!=build is an added bonus, but 
ac> not a requrement.  We can hardly enforce host!=build when there's no way 
ac> to test it and the return on investment is marginal.

The machine resources are easy to get.  build == my laptop,
host == hp test drive machine (they support inbound telnet and ftp).
All I have to do is write a board file!

I'm going to move off the status quo in one direction or the other.
Either build != host is supported, or it's not.  If it is supported,
then I have to test it (sigh), and at least characterize how many tests
are broken.  If it's not supported, then I want the doco to say so.

Michael C

breaking at for-loop test line

[Allen Hopkins]

Is there a way to break at the test statement of a for-loop 
on every iteration, the same way a while-loop works?  Here's
what I mean:

      1	#include <iostream.h>
      2	
      3	int main(int argc, char* argv[])
      4	{
      5	    int i = 0;
      6	
      7	    for (i = 0; i < 3; i++) {
      8	        cout << i << endl;
      9	    }
     10	
     11	    while (i < 6) {
     12	        cout << i++ << endl;
     13	    }
     14	
     15	    exit(0);
     16	}

If I set a breakpoint at line 7, and another at line 11,
and "run" and "continue" until exit, it will only break once
on the for-loop, but it will break on each iteration of the
while-loop.  How does this make sense?  Is there any way to
get a breakpoint at the top of the for-loop to act like the
while-loop?

Here's the compile command:
> g++ -ggdb -Wno-deprecated -o s s.cpp

There's no optimization going on that I'm not aware of,
is there?

Here's sample gdb output:
(gdb) break 7
Breakpoint 1 at 0x10b04: file s.cpp, line 7.
(gdb) break 11
Breakpoint 2 at 0x10b5c: file s.cpp, line 11.
(gdb) run
Starting program: 
/export/home/allenh/projects/metropolis/testing/foodir/s

Breakpoint 1, main (argc=1, argv=0xffbeecac) at s.cpp:7
7	    for (i = 0; i < 3; i++) {
(gdb) c
Continuing.
0
1
2

Breakpoint 2, main (argc=1, argv=0xffbeecac) at s.cpp:11
11	    while (i < 6) {
(gdb) c
Continuing.
3

Breakpoint 2, main (argc=1, argv=0xffbeecac) at s.cpp:11
11	    while (i < 6) {
(gdb) c
Continuing.
4

Breakpoint 2, main (argc=1, argv=0xffbeecac) at s.cpp:11
11	    while (i < 6) {
(gdb) c
Continuing.
5

Breakpoint 2, main (argc=1, argv=0xffbeecac) at s.cpp:11
11	    while (i < 6) {
(gdb) c
Continuing.

Program exited normally.
(gdb)

Any advice appreciated.

Oh, yeah...

	Sun Solaris 2.8
	gcc 3.2.2
	gdb 6.0

Thanks.
-Allen Hopkins
UC Berkeley

Re: breaking at for-loop test line

[Daniel Jacobowitz]

On Wed, Jul 28, 2004 at 04:09:14PM -0700, Allen Hopkins wrote:
> Is there a way to break at the test statement of a for-loop 
> on every iteration, the same way a while-loop works?  Here's
> what I mean:
> 
>      1	#include <iostream.h>
>      2	
>      3	int main(int argc, char* argv[])
>      4	{
>      5	    int i = 0;
>      6	
>      7	    for (i = 0; i < 3; i++) {
>      8	        cout << i << endl;
>      9	    }
>     10	
>     11	    while (i < 6) {
>     12	        cout << i++ << endl;
>     13	    }
>     14	
>     15	    exit(0);
>     16	}
> 
> If I set a breakpoint at line 7, and another at line 11,
> and "run" and "continue" until exit, it will only break once
> on the for-loop, but it will break on each iteration of the
> while-loop.  How does this make sense?  Is there any way to
> get a breakpoint at the top of the for-loop to act like the
> while-loop?

What Atul wrote is basically correct; GDB can only pick one breakpoint
location for a particular line number, and it picks the beginning of
the line.

It would be nice if there were a way to set a breakpoint at the
condition, but we don't have enough information to know for sure where
the "condition" part is; and we don't want to always set breakpoints at
every part of a line, because it makes breakpoints on simple statements
that get broken up by ptimization very awkward to work with.

I've been thinking for a while about a better interface for this, but I
haven't come up with one yet.

In the mean time, you can take a look at the disassembly, figure out
where the condition is, and set a breakpoint there using break *<addr>.
GDB could also make it much easier to figure out where the condition is
than it does now...

-- 
Daniel Jacobowitz

Re: breaking at for-loop test line

[Andre Ancelin]

On Thursday 29 July 2004 11:29, Daniel Jacobowitz wrote:

This works.

      7	    for (i = 0; i < 3; 
      8          i++) {
      9 	        cout << i << endl;
      10    }

with a breakpoint at 8. It will stop for each pass. If you try

      7	    for (i = 0;
      8          i < 3; 
      9          i++) {
      10 	        cout << i << endl;
      11    }

with breakpoints at 7, 8, & 9, you stop at each line once, then at line 9 two 
more times, then out. It does not, however, stop again at line 8 for each 
pass or at terminus (?). You can, however, add a breakpoint on line 11 and 
you will break at the next statement after line 11 upon terminus.

Some might call this style ugly or wasteful, but I have found it much more 
debug friendly to leave all conditional tests on lines by themselves. Another 
simple example:

	if (i < 6 ||
	    i > 9)
		{
		<do_something>
		}

> On Wed, Jul 28, 2004 at 04:09:14PM -0700, Allen Hopkins wrote:
> > Is there a way to break at the test statement of a for-loop
> > on every iteration, the same way a while-loop works?  Here's
> > what I mean:
> >
> >      1	#include <iostream.h>
> >      2
> >      3	int main(int argc, char* argv[])
> >      4	{
> >      5	    int i = 0;
> >      6
> >      7	    for (i = 0; i < 3; i++) {
> >      8	        cout << i << endl;
> >      9	    }
> >     10
> >     11	    while (i < 6) {
> >     12	        cout << i++ << endl;
> >     13	    }
> >     14
> >     15	    exit(0);
> >     16	}
> >
> > If I set a breakpoint at line 7, and another at line 11,
> > and "run" and "continue" until exit, it will only break once
> > on the for-loop, but it will break on each iteration of the
> > while-loop.  How does this make sense?  Is there any way to
> > get a breakpoint at the top of the for-loop to act like the
> > while-loop?
>
> What Atul wrote is basically correct; GDB can only pick one breakpoint
> location for a particular line number, and it picks the beginning of
> the line.
>
> It would be nice if there were a way to set a breakpoint at the
> condition, but we don't have enough information to know for sure where
> the "condition" part is; and we don't want to always set breakpoints at
> every part of a line, because it makes breakpoints on simple statements
> that get broken up by ptimization very awkward to work with.
>
> I've been thinking for a while about a better interface for this, but I
> haven't come up with one yet.
>
> In the mean time, you can take a look at the disassembly, figure out
> where the condition is, and set a breakpoint there using break *<addr>.
> GDB could also make it much easier to figure out where the condition is
> than it does now...

-- 
Andre Ancelin
VP/CTO Adtec Digital, Inc
andrea@adtecinc.com
www.adtecinc.com

Re: breaking at for-loop test line

[Felix Lee]

Daniel Jacobowitz <drow@false.org>:
> I've been thinking for a while about a better interface for this, but I
> haven't come up with one yet.
> 
> In the mean time, you can take a look at the disassembly, figure out
> where the condition is, and set a breakpoint there using break *<addr>.
> GDB could also make it much easier to figure out where the condition is
> than it does now...

how about just that.  something like "asm 30" that will print all
the machine instructions that correspond to line 30 of the
source.  in a gui, this would be something like, selecting a
source line would highlight the corresponding lines in a
disassembly window.  or in a mixed source/asm window, an option
to choose whether it's ordered by source or by asm.
--

Re: breaking at for-loop test line

[Baurjan Ismagulov]

Hello Felix,

On Thu, Jul 29, 2004 at 11:58:40AM -0700, Felix Lee wrote:
> how about just that.  something like "asm 30" that will print all
> the machine instructions that correspond to line 30 of the
> source.

Do you mean something like the following?

(gdb) info line 223
Line 223 of "main.c" starts at address 0x804e384 <main+64>
   and ends at 0x804e3a0 <main+92>.
(gdb) disas 0x804e384 0x804e3a0

With kind regards,
Baurjan.

Re: breaking at for-loop test line

[Felix Lee]

Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>:
> On Thu, Jul 29, 2004 at 11:58:40AM -0700, Felix Lee wrote:
> > how about just that.  something like "asm 30" that will print all
> > the machine instructions that correspond to line 30 of the
> > source.
> 
> Do you mean something like the following?
> 
> (gdb) info line 223
> Line 223 of "main.c" starts at address 0x804e384 <main+64>
>    and ends at 0x804e3a0 <main+92>.
> (gdb) disas 0x804e384 0x804e3a0

yeah, but it would be nice to take into account code optimization
and exclude instructions in that range that aren't relevant to
line 223.  but I don't know if there's enough debugging
information to do that.
--

Re: breaking at for-loop test line

[Eli Zaretskii]

> Date: Thu, 29 Jul 2004 11:29:40 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> I've been thinking for a while about a better interface for this, but I
> haven't come up with one yet.

Does GCC tell us in any way (via the debug info) that a single source
line has more than a single statement?

If not, the only way for GDB to figure that out is to parse the source
code by itself.

> GDB could also make it much easier to figure out where the condition is
> than it does now...

How?

Re: breaking at for-loop test line

[Daniel Jacobowitz]

On Fri, Jul 30, 2004 at 01:23:05AM -0700, Felix Lee wrote:
> Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>:
> > On Thu, Jul 29, 2004 at 11:58:40AM -0700, Felix Lee wrote:
> > > how about just that.  something like "asm 30" that will print all
> > > the machine instructions that correspond to line 30 of the
> > > source.
> > 
> > Do you mean something like the following?
> > 
> > (gdb) info line 223
> > Line 223 of "main.c" starts at address 0x804e384 <main+64>
> >    and ends at 0x804e3a0 <main+92>.
> > (gdb) disas 0x804e384 0x804e3a0
> 
> yeah, but it would be nice to take into account code optimization
> and exclude instructions in that range that aren't relevant to
> line 223.  but I don't know if there's enough debugging
> information to do that.

There is.  We may want to "fix" the output of info line.  What it is
right now is the first group of contiguous instructions in the line;
later groups are ignored.

-- 
Daniel Jacobowitz

Re: breaking at for-loop test line

[Daniel Jacobowitz]

On Fri, Jul 30, 2004 at 01:43:28PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 29 Jul 2004 11:29:40 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > I've been thinking for a while about a better interface for this, but I
> > haven't come up with one yet.
> 
> Does GCC tell us in any way (via the debug info) that a single source
> line has more than a single statement?
> 
> If not, the only way for GDB to figure that out is to parse the source
> code by itself.

No, it doesn't, but there is more information available from the
machine code than there is from the source code.  For "for" statements,
it's conceivable to work out that there are multiple places in the
statement which serve as branch targets, via assembly analysis.  Better
would be to record this in the debug info; there's no way to do it,
yet, but someone was bouncing around a proposal to record it in the
line table.

> > GDB could also make it much easier to figure out where the condition is
> > than it does now...
> 
> How?

By providing a version of "info line" which described all the ranges of
code belonging to a line instead of just the first one, or by a command
which disassembled an entire line.

-- 
Daniel Jacobowitz

Re: breaking at for-loop test line

[Andrew Cagney]

> On Fri, Jul 30, 2004 at 01:43:28PM +0200, Eli Zaretskii wrote:
> 
>>>> > Date: Thu, 29 Jul 2004 11:29:40 -0400
>>>> > From: Daniel Jacobowitz <drow@false.org>
>>>> > 
>>>> > I've been thinking for a while about a better interface for this, but I
>>>> > haven't come up with one yet.
>>
>>> 
>>> Does GCC tell us in any way (via the debug info) that a single source
>>> line has more than a single statement?
>>> 
>>> If not, the only way for GDB to figure that out is to parse the source
>>> code by itself.
> 
> 
> No, it doesn't, but there is more information available from the
> machine code than there is from the source code.  For "for" statements,
> it's conceivable to work out that there are multiple places in the
> statement which serve as branch targets, via assembly analysis.  Better
> would be to record this in the debug info; there's no way to do it,
> yet, but someone was bouncing around a proposal to record it in the
> line table.

Does dwarf3 include column information? That would let us break:

    for (i ; i < 10 ; i++)

into:

    for (i ;
             i < 10 ;
                      i++)

which, at least on a graphics device, could be very effectively 
represented to the user - the section of code to next be executed could 
be highlighted.

Andrew

>>>> > GDB could also make it much easier to figure out where the condition is
>>>> > than it does now...
>>
>>> 
>>> How?
> 
> 
> By providing a version of "info line" which described all the ranges of
> code belonging to a line instead of just the first one, or by a command
> which disassembled an entire line.
> 

Re: breaking at for-loop test line

[Daniel Jacobowitz]

On Tue, Aug 03, 2004 at 04:08:54PM -0400, Andrew Cagney wrote:
> Does dwarf3 include column information? That would let us break:
> 
>    for (i ; i < 10 ; i++)
> 
> into:
> 
>    for (i ;
>             i < 10 ;
>                      i++)
> 
> which, at least on a graphics device, could be very effectively 
> represented to the user - the section of code to next be executed could 
> be highlighted.

Hmm, yes - the line table does have a field for column.  GCC is working
on tracking columns internally, so after that, it shouldn't be too
difficult to make it output appropriate line table data.

-- 
Daniel Jacobowitz

GDB/XMI (XML Machine Interface)

[Bob Rossi]

Hi,

As most of you know, I have been writing a front end to GDB called CGDB.
However, for a while now, I have been a little disappointed with the MI
interface. In my RFC I have described the problems I have with MI and I
have proposed a new method of communication between GDB and the front
end.

If there is good feedback on this RFC, I will continue research on it,
filling in details that I thought would be best to wait until after an
initial acceptance.

If the RFC is accepted by the community I plan on implementing an
initial version of the XMI interface in GDB, and programming CGDB to 
sit on top of GDB. This will at least give the community one open 
source front end to GDB and an example to prove that the new 
machine interface works.

I can't wait to hear your opinions/comments.

Thanks,
Bob Rossi

                       GDB/XMI (XML Machine Interface)

                               Robert Rossi
                               August 2004
                               bob@brasko.net


                             TABLE OF CONTENTS

1. Introduction
  1.1 The Problem
  1.2 The Objective

2. The GDB/XMI Overview
  2.1 Passing Information between GDB and the front end
  2.2 Parsing XMI Commands from GDB's output
  2.3 Parsing the Inferior's output
  2.4 Validation
  2.5 Version Management
  2.6 Understanding the XML data

3. GDB/XMI Specification
  3.1 XMI Types
    3.1.1 Scalar Types
    3.1.2 Compound Types (Structs)
  3.2 A Breakpoint Listing
    3.2.1 The GDB/MI -break-list Specification
    3.2.2 GDB/MI Output
    3.2.3 The GDB/XMI Output
  3.3 A Backtrace
    3.3.1 The GDB/MI -stack-list-frames Specification
    3.3.2 GDB/MI Output
    3.3.3 The GDB/XMI Output

4. A GDB/XMI Example
  4.1 The Inferior's Code
  4.2 GDB/MI Output
  4.3 GDB/XMI Output
  4.4 A Brief Description of the XMI output
    4.4.1 GDB_DISPLAY_PROMPT Document
    4.4.2 GDB_WAITING_FOR_COMMAND Document
    4.4.3 The Front End Transmits a Command
    4.4.4 GDB_INFERIOR_STARTED Document
    4.4.5 GDB_INFERIOR_FINISHED Document

5. Issues to resolve after RFC Initial approval.
  5.1 If GDB will link to libxml, or just output XML
  5.2 How the schema will represent each document sent to the front end
  5.3 Separating GDB output and the Inferior output 
  5.4 If GDB recieves commands in XML

Preface

  GDB/XMI is meant to be the successor of GDB/MI. It improves upon the
  idea of GDB/MI and fixes many of the known issues that GDB/MI contains.

1. Introduction
  1.1 The Problem

  Writing a front end for GDB/MI means that a front end has to be able to
  implement an ad hoc parser, capable of understanding all of the data 
  sent from GDB to it. For each version of GDB, functionality might change, 
  without ever allowing the GUI to understand what the interface differences
  are in a scientific manner. Any guessing from version to version is a 
  best-chance scenario, leaving the front end guessing what functionality
  a CVS snapshot has that has been installed on any particular distribution.

  1.2 The Objective

  The objective of GDB/XMI is to create a reliable protocol between
  GDB and the front end controlling GDB. A goal of this project is to
  remove most of the parsing from the front end, and move it to a
  reliable parsing library, capable of validating the data it is 
  parsing, and building a tree representation of the data without 
  any front end infrastructure. It is believed that the protocol between 
  GDB and any front end can be automated in every front end and that it 
  is not necessary to have any front end developer worry about the syntax
  or grammar of the actual commands sent between GDB and the front end.

  Another goal of this project is to formalize the maintenance and
  version management of the XMI commands, as GDB matures, and modifies the
  XMI commands over time. The front end should be independent of the
  XMI command versions, and should be able to determine what data is
  available to it, without worrying about the version of any particular
  XMI command.
 
  It is believed this can help front end writers in several ways. First,
  there will be a significant reduction of time spent in parsing the 
  obscure MI commands, and understanding what the output represents.
  This gives front end developers a greater chance of actually getting
  to 1.0 on any given front end, and allowing for much more time to 
  be spent on the look & feel of the front end, not including the much
  needed features that most front ends do not have. Secondly, It will
  reduce the code size of each front end, potentially reducing the number 
  of bugs, and allowing for a more reliable set of front ends that sit 
  on top of GDB. 

2. The GDB/XMI Overview

  GDB/XMI is based mostly on the model of GDB/MI. The major differences 
  are the need to pass the information from GDB to the front end via XML
  documents and the ability to give the front end a schema, capable 
  of validating an XMI command.

  2.1 Passing Information between GDB and the front end

  All information passed between GDB and the front end is done in
  the form of an XML document. Each XMI command, generates an XML
  document, and is sent from GDB to the front end.

  2.2 Parsing XMI Commands from GDB's output

  XMI is the protocol between GDB and the front end. It is an XML
  based Markup Language that is intended to be the Machine Interface
  between GDB and any application that would like to communicate with it.
  
  An XML document is started and stopped with escape sequences. These
  sequences tell the front end when an XML document is being sent, and
  when the XML document is done being sent. For each XMI command, GDB 
  will output an escape sequence saying that it is ready to transmit
  the XML Document response. Then it will output the XML Document. Finally,
  GDB will transmit another escape sequence, saying that the document 
  has been completed. This allows the front end to understand what 
  information to pass to the XML parser, and what information is output
  from the inferior.

  2.3 Parsing the Inferior's output
  
  When the GDB sends the XML command stating that the inferior has started, 
  the front end can then parse the output of GDB waiting for an escape
  sequence, saying that the inferior has stopped running. All of the 
  data captured between these two points are output from the inferior.
  It can be processed real time and sent to the user to update them of what 
  the inferior is doing. Any asynchronous commands can of course break the
  stream and output data to the front end, and then notify the front end
  that the inferior has started again. This easily allows the front end
  to understand what data is from GDB and what data is from the inferior.
  The only downside to this design is that escape sequences are needed.
  However, the only way to change that is to allow the inferior's output
  to be on a separate communication link (pipe) than the output of GDB.
  So far, this has not happened. Section 5, point 3 illustrates that it
  would be desirable to split GDB's and the inferior's output up, this
  would cause the protocol between GDB and the front end to not include
  the escape sequences before and after each XMI document sent.

  2.4 Validation
  The validation document (DTD) has to be up to date with the XMI 
  command for the particular version of GDB. Also, this document has to
  be in one place. Therefore, I propose, that an XMI command be given to
  output to the front end all of the XMI validation documents (DTD?) or
  pass a parameter to have GDB output the validation document for a 
  particular XMI command. This document will prove that the XMI commands
  are valid, and GDB is not misbehaving. Front end writers can report
  bad output from GDB easily, and the development process can self-adjust.

  The main goal of this tactic is that GDB is capable of telling front ends
  if the output it is generating is correct. Front ends can use this 
  capability, at virtually no extra cost, to determine if the protocol
  between the two processes is incorrect. By allowing GDB to keep the 
  Schema's, the DRY principle is honored, and things will not get out of
  date.

  2.5 Version Management

  From version to version, XMI commands will be modified. Commands will
  be fully backwards compatible, from version to version, allowing only
  fields to be added, or providing more information than is already 
  there. The front ends will not have to be updated in this way, 
  allowing existing front ends to always be able to use at least the 
  amount of information that they have been programmed to understand.

  Since it is not a perfect world, it is not always possible to make 
  XMI commands backwards compatible. In this case, the XMI command to
  be replaced will be marked as deprecated and a new XMI command will
  be generated to take it's place. This new command will force the 
  front end writer to program the functionality of the new command into
  there program, and from then on, will again have a front end capable
  of parsing the new command with a new GDB, and the old command with 
  the old GDB.

  This model keeps front ends working with both old and new GDB's, which
  is unfortunately a task that most front ends have to and should deal with.

  2.6 Understanding the XML data

  Since all commands are backwards compatible, the tree representation
  for any XMI command can be walked the same way, no matter what version
  of the XMI command is being used. The front end is capable of throwing
  away any data that it does not know how or wish to process, allowing
  it to pick and choose what data is appropriate.

3. GDB/XMI Specification

  3.1 XMI Types

  The XMI types are to be used for validation purposes. They can also
  be used to tell the front end what kind of type a particular element
  is that GDB is sending to the front end.

  3.1.1 Scalar Types

  <int8>      one-byte singed integer
  <uint8>     one-byte unsigned integer
  <int16>     two-byte signed integer
  <uint16>    two-byte unsigned integer
  <int32>     four-byte signed integer
  <uint32>    four-byte unsigned integer
  <int64>     eight-byte signed integer
  <uint64>    eight-byte unsigned integer
  <boolean>   0 (false) or 1 (true)
  <string>    string
  <float>     single-precision signed floating point number
  <double>    double-precision signed floating point number

  3.1.2 Compound Types (Structs)

  A "struct" is a compound value in which accessor name is the only 
  distinction among member values, and no accessor has the same name 
  as any other.

  <struct_example>
    <element_one>one</element_one>
    <element_two>two</element_two>
    <element_three>three</element_three>
  </struct_example>

  A Schema for such a struct could look like this.

  <element name="struct_example">
    <complexType>
      <element name="element_one" type="string"/>
      <element name="element_two" type="string"/>
      <element name="element_three" type="string"/>
    </complexType>
  </struct_example>

  3.2 A Breakpoint Listing

  3.2.1 The GDB/MI -break-list Specification
  The -break-list Command

  Displays the list of inserted breakpoints, showing the following fields:

  `Number'
    number of the breakpoint 
  `Type'
    type of the breakpoint: `breakpoint' or `watchpoint' 
  `Disposition'
    should the breakpoint be deleted or disabled when it is hit: 
    `keep' or `nokeep' `Enabled' is the breakpoint enabled or no: 
    `y' or `n' 
  `Address'
    memory location at which the breakpoint is set 
  `What'
    logical location of the breakpoint, expressed by function name, 
    file name, line number 
  `Times'
    number of times the breakpoint has been hit 

  If there are no breakpoints or watchpoints, the BreakpointTable body 
  field is an empty list. 

  3.2.2 GDB/MI Output

  -break-list
  ^done,
  BreakpointTable={
    nr_rows="4",nr_cols="6",
    hdr=[
      {width="3",alignment="-1",col_name="number",colhdr="Num"},
      {width="14",alignment="-1",col_name="type",colhdr="Type"},
      {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
      {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
      {width="10",alignment="-1",col_name="addr",colhdr="Address"},
      {width="40",alignment="2",col_name="what",colhdr="What"}
    ],
    body=[
      bkpt={
        number="1",type="breakpoint",disp="keep",enabled="y",
        addr="0x0804844f",func="main",file="test.c",line="35",times="1"},
      bkpt={
        number="2",type="breakpoint",disp="keep",enabled="y",
        addr="0x080483ef",func="short_func",file="test.c",line="13",times="0"},
      bkpt={
        number="3",type="breakpoint",disp="keep",enabled="y",
        addr="0x0804851d",func="main",file="test.c",line="61",times="0"},
      bkpt={
        number="4",type="hw watchpoint",disp="keep",enabled="y",addr="",
        what="argc",times="0"}
      ]
    }

  3.2.3 The GDB/XMI Output

  <?xml version="1.0"?>
  <breakpoints>
    <breakpoint>
      <number>1</number>
      <type>breakpoint</type>
      <disp>keep</disp>
      <enabled>1</enabled>
      <addr>0x0804844f</addr>
      <func>main</func>
      <file>test.c</file>
      <line>35</line>
      <times>0</times>
    </breakpoint>
    <breakpoint>
      <number>2</number>
      <type>breakpoint</type>
      <disp>keep</disp>
      <enabled>1</enabled>
      <addr>0x080483ef</addr>
      <func>short_func</func>
      <file>test.c</file>
      <line>13</line>
      <times>0</times>
    </breakpoint>
    <breakpoint>
      <number>3</number>
      <type>breakpoint</type>
      <disp>keep</disp>
      <enabled>1</enabled>
      <addr>0x0804851d</addr>
      <func>main</func>
      <file>test.c</file>
      <line>61</line>
      <times>0</times>
    </breakpoint>
    <watchpoint>
      <number>4</number>
      <type>watchpoint</type>
      <disp>keep</disp>
      <enabled>1</enabled>
      <addr></addr>
      <what>argc</what>
      <times>0</times>
    </watchpoint>
  </breakpoints>

  3.3 A Backtrace

  3.3.1 The GDB/MI -stack-list-frames Specification

  The -stack-list-frames Command

  Synopsis: -stack-list-frames [ low-frame high-frame ]

  List the frames currently on the stack. For each frame it displays 
  the following info:

  `level'
    The frame number, 0 being the topmost frame, 
    i.e. the innermost function. 
  `addr'
    The $pc value for that frame. 
  `func'
    Function name. 
  `file'
    File name of the source file where the function lives. 
  `line'
    Line number corresponding to the $pc. 

  If invoked without arguments, this command prints a backtrace for 
  the whole stack. If given two integer arguments, it shows the frames 
  whose levels are between the two arguments (inclusive). If the two 
  arguments are equal, it shows the single frame at the corresponding level. 

  3.3.2 GDB/MI Output

  (gdb)
  -stack-list-frames
  ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file="test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file="test.c",line="54"}]

  ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
  file="test.c",line="13"},frame={level="1",addr="0x080484f5",
  func="main",file="test.c",line="54"}]

  3.3.3 The GDB/XMI Output
    
  <?xml version="1.0"?>
  <stack>
    <frame>
      <level>0</level>
      <addr>0x080483ef</addr>
      <func>short_func</func>
      <file>test.c</file>
      <line>13</line>
    </frame>
    <frame>
      <level>1</level>
      <addr>0x080484f5</addr>
      <func>main</func>
      <file>test.c</file>
      <line>54</line>
    </frame>
  </stack>

4. A GDB/XMI Example
  
  4.1 The Inferior's Code
  #include <stdio.h>
  int main(int argc, char **argv){
    printf ( "newline\n" e;
    printf ( "nonewline" );
    return 0;
  }

  4.2 GDB/MI Output
    (gdb)
    -exec-run
    ^running
    (gdb)
    newline
    nonewline*stopped,reason="exited-normally"
    (gdb)

  4.3 GDB/XMI Output
  Assuming that the escape sequence is simply \027
  The whitespace is not necessary, and is simply there for presentation.

  \027<GDB_DISPLAY_PROMPT>
  (gdb) 
  </GDB_DISPLAY_PROMPT>\027
  \027<GDB_WAITING_FOR_COMMAND/>\027
  -exec-run
  \027<GDB_INFERIOR_STARTED/>\027
  newline
  nonewline\027<GDB_INFERIOR_FINISHED/>\027
  \027<GDB_DISPLAY_PROMPT>
  gdb
  </GDB_DISPLAY_PROMPT>\027
  \027<GDB_WAITING_FOR_COMMAND/>\027

  4.4 A Brief Description of the XMI output
  
    4.4.1 GDB_DISPLAY_PROMPT Document
    The front end receives the document below.
      \027<GDB_DISPLAY_PROMPT>
      (gdb) 
      </GDB_DISPLAY_PROMPT>\027
    The front end sends the data to the XML processor, which then tells
    it that the current prompt is "(gdb) ". The front end can choose to
    do whatever it wants with this information, including display it to the
    user, or just ignore it.

    4.4.2 GDB_WAITING_FOR_COMMAND Document
    Next, GDB transmits the document below.
      \027<GDB_WAITING_FOR_COMMAND/>\027
    The front end receives the data and sends it to the XML processor. The
    processor parses the document and the front end can determine that 
    the command says that GDB is ready to accept a user command. At this
    point, the front end understands that it is OK to transmit a command to
    GDB.

    4.4.3 The Front End Transmits a Command
    The front end transmits the command "-exec-run".
    Should the front end transmit commands in XML or just 
    ordinary text?

    4.4.4 GDB_INFERIOR_STARTED Document
    GDB would send a document telling the front end that the inferior
    has begun processing.
      \027<GDB_INFERIOR_STARTED/>\027
    Everything the front end processes from the pipe from this point 
    until the next GDB XMI Document transmission is from the inferior.
    It is considered to be output that the inferior would like to have
    the user see. The front end can process this data realtime, since
    it does not have to be sent to the XML parser for processing.

    The data
      newline
      nonewline
      is outputted by the inferior, and the front end processes this data
    realtime, understanding that it is not the output of GDB.

    4.4.5 GDB_INFERIOR_FINISHED Document
    GDB would send a document telling the front end that the inferior
    has finished processing.
      \027<GDB_INFERIOR_FINISHED/>\027

    This alerts the front end that GDB is now outputting XMI commands
    again. The front end no longer expects information from the inferior.
    Optionally, GDB could output a XMI command stating that a signal 
    has been caught, or some other asynchronous event has occurred. This
    could be something like
      \027<GDB_SIGNAL_CAUGHT>
      <SIGNAL>
        <NAME>SIGINT</NAME>
        <NUMBER>2</NUMBER>
        <COMMENT>Interrupt from keyboard</COMMENT>
      </SIGNAL>
      </GDB_SIGNAL_CAUGHT>\027
    In this way, GDB could alert the front end of any asynchronous event,
    and no special parsing mechanism will have to take place to 
    understand such actions.

5. Issues to resolve after RFC Initial approval.

  5.1 If GDB will link to libxml, or just output XML
    It would be nice if GDB was capable of sending the XML documents by
    creating them via libxml. However, libxml2 is licensed under the
    MIT license. Also, I don't know if libxml2 is as portable as GDB.

  5.2 How the schema will represent each document sent to the front end
    If there will be one schema for each XMI document, or a schema
    that represents every XMI document.

  5.3 Separating GDB output and the Inferior output 
    If GDB can output it's data on a different pipe than the 
    inferior then the escape sequences would not be needed to tell
    the front end which data is from GDB and which is from the inferior.

    This would simply the front end processing.

  5.4 If GDB recieves commands in XML
    If GDB links in libxml2, then it could easy receive commands from the
    front end in XML. This would be a nice feature, although, since the
    parser in GDB is only written once, it doesn't really matter what format 
    the commands are that is sent to it.

Re: GDB/XMI (XML Machine Interface)

[Kip Macy]

Excellent. I've been thinking about the same thing for quite some time,
but have hesitated to propose it because of the animosity towards XML
that I see in many places in the OSS community. It seems that many
prefer to create a new format for every application.

The actual MI output is not anywhere nearly as clean as the grammar that
is documented. My parser (which I would not have had to spend days
writing and debugging if MI were XML) has a larger number of actions
than is documented. And yet there are still many cases that it cannot
handle.

I would eagerly support this effort.


					-Kip


On Tue, 10 Aug 2004, Bob Rossi wrote:

> Hi,
>
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
>
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
>
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to
> sit on top of GDB. This will at least give the community one open
> source front end to GDB and an example to prove that the new
> machine interface works.
>
> I can't wait to hear your opinions/comments.
>
> Thanks,
> Bob Rossi
>
>                        GDB/XMI (XML Machine Interface)
>
>                                Robert Rossi
>                                August 2004
>                                bob@brasko.net
>
>
>                              TABLE OF CONTENTS
>
> 1. Introduction
>   1.1 The Problem
>   1.2 The Objective
>
> 2. The GDB/XMI Overview
>   2.1 Passing Information between GDB and the front end
>   2.2 Parsing XMI Commands from GDB's output
>   2.3 Parsing the Inferior's output
>   2.4 Validation
>   2.5 Version Management
>   2.6 Understanding the XML data
>
> 3. GDB/XMI Specification
>   3.1 XMI Types
>     3.1.1 Scalar Types
>     3.1.2 Compound Types (Structs)
>   3.2 A Breakpoint Listing
>     3.2.1 The GDB/MI -break-list Specification
>     3.2.2 GDB/MI Output
>     3.2.3 The GDB/XMI Output
>   3.3 A Backtrace
>     3.3.1 The GDB/MI -stack-list-frames Specification
>     3.3.2 GDB/MI Output
>     3.3.3 The GDB/XMI Output
>
> 4. A GDB/XMI Example
>   4.1 The Inferior's Code
>   4.2 GDB/MI Output
>   4.3 GDB/XMI Output
>   4.4 A Brief Description of the XMI output
>     4.4.1 GDB_DISPLAY_PROMPT Document
>     4.4.2 GDB_WAITING_FOR_COMMAND Document
>     4.4.3 The Front End Transmits a Command
>     4.4.4 GDB_INFERIOR_STARTED Document
>     4.4.5 GDB_INFERIOR_FINISHED Document
>
> 5. Issues to resolve after RFC Initial approval.
>   5.1 If GDB will link to libxml, or just output XML
>   5.2 How the schema will represent each document sent to the front end
>   5.3 Separating GDB output and the Inferior output
>   5.4 If GDB recieves commands in XML
>
> Preface
>
>   GDB/XMI is meant to be the successor of GDB/MI. It improves upon the
>   idea of GDB/MI and fixes many of the known issues that GDB/MI contains.
>
> 1. Introduction
>   1.1 The Problem
>
>   Writing a front end for GDB/MI means that a front end has to be able to
>   implement an ad hoc parser, capable of understanding all of the data
>   sent from GDB to it. For each version of GDB, functionality might change,
>   without ever allowing the GUI to understand what the interface differences
>   are in a scientific manner. Any guessing from version to version is a
>   best-chance scenario, leaving the front end guessing what functionality
>   a CVS snapshot has that has been installed on any particular distribution.
>
>   1.2 The Objective
>
>   The objective of GDB/XMI is to create a reliable protocol between
>   GDB and the front end controlling GDB. A goal of this project is to
>   remove most of the parsing from the front end, and move it to a
>   reliable parsing library, capable of validating the data it is
>   parsing, and building a tree representation of the data without
>   any front end infrastructure. It is believed that the protocol between
>   GDB and any front end can be automated in every front end and that it
>   is not necessary to have any front end developer worry about the syntax
>   or grammar of the actual commands sent between GDB and the front end.
>
>   Another goal of this project is to formalize the maintenance and
>   version management of the XMI commands, as GDB matures, and modifies the
>   XMI commands over time. The front end should be independent of the
>   XMI command versions, and should be able to determine what data is
>   available to it, without worrying about the version of any particular
>   XMI command.
>
>   It is believed this can help front end writers in several ways. First,
>   there will be a significant reduction of time spent in parsing the
>   obscure MI commands, and understanding what the output represents.
>   This gives front end developers a greater chance of actually getting
>   to 1.0 on any given front end, and allowing for much more time to
>   be spent on the look & feel of the front end, not including the much
>   needed features that most front ends do not have. Secondly, It will
>   reduce the code size of each front end, potentially reducing the number
>   of bugs, and allowing for a more reliable set of front ends that sit
>   on top of GDB.
>
> 2. The GDB/XMI Overview
>
>   GDB/XMI is based mostly on the model of GDB/MI. The major differences
>   are the need to pass the information from GDB to the front end via XML
>   documents and the ability to give the front end a schema, capable
>   of validating an XMI command.
>
>   2.1 Passing Information between GDB and the front end
>
>   All information passed between GDB and the front end is done in
>   the form of an XML document. Each XMI command, generates an XML
>   document, and is sent from GDB to the front end.
>
>   2.2 Parsing XMI Commands from GDB's output
>
>   XMI is the protocol between GDB and the front end. It is an XML
>   based Markup Language that is intended to be the Machine Interface
>   between GDB and any application that would like to communicate with it.
>
>   An XML document is started and stopped with escape sequences. These
>   sequences tell the front end when an XML document is being sent, and
>   when the XML document is done being sent. For each XMI command, GDB
>   will output an escape sequence saying that it is ready to transmit
>   the XML Document response. Then it will output the XML Document. Finally,
>   GDB will transmit another escape sequence, saying that the document
>   has been completed. This allows the front end to understand what
>   information to pass to the XML parser, and what information is output
>   from the inferior.
>
>   2.3 Parsing the Inferior's output
>
>   When the GDB sends the XML command stating that the inferior has started,
>   the front end can then parse the output of GDB waiting for an escape
>   sequence, saying that the inferior has stopped running. All of the
>   data captured between these two points are output from the inferior.
>   It can be processed real time and sent to the user to update them of what
>   the inferior is doing. Any asynchronous commands can of course break the
>   stream and output data to the front end, and then notify the front end
>   that the inferior has started again. This easily allows the front end
>   to understand what data is from GDB and what data is from the inferior.
>   The only downside to this design is that escape sequences are needed.
>   However, the only way to change that is to allow the inferior's output
>   to be on a separate communication link (pipe) than the output of GDB.
>   So far, this has not happened. Section 5, point 3 illustrates that it
>   would be desirable to split GDB's and the inferior's output up, this
>   would cause the protocol between GDB and the front end to not include
>   the escape sequences before and after each XMI document sent.
>
>   2.4 Validation
>   The validation document (DTD) has to be up to date with the XMI
>   command for the particular version of GDB. Also, this document has to
>   be in one place. Therefore, I propose, that an XMI command be given to
>   output to the front end all of the XMI validation documents (DTD?) or
>   pass a parameter to have GDB output the validation document for a
>   particular XMI command. This document will prove that the XMI commands
>   are valid, and GDB is not misbehaving. Front end writers can report
>   bad output from GDB easily, and the development process can self-adjust.
>
>   The main goal of this tactic is that GDB is capable of telling front ends
>   if the output it is generating is correct. Front ends can use this
>   capability, at virtually no extra cost, to determine if the protocol
>   between the two processes is incorrect. By allowing GDB to keep the
>   Schema's, the DRY principle is honored, and things will not get out of
>   date.
>
>   2.5 Version Management
>
>   From version to version, XMI commands will be modified. Commands will
>   be fully backwards compatible, from version to version, allowing only
>   fields to be added, or providing more information than is already
>   there. The front ends will not have to be updated in this way,
>   allowing existing front ends to always be able to use at least the
>   amount of information that they have been programmed to understand.
>
>   Since it is not a perfect world, it is not always possible to make
>   XMI commands backwards compatible. In this case, the XMI command to
>   be replaced will be marked as deprecated and a new XMI command will
>   be generated to take it's place. This new command will force the
>   front end writer to program the functionality of the new command into
>   there program, and from then on, will again have a front end capable
>   of parsing the new command with a new GDB, and the old command with
>   the old GDB.
>
>   This model keeps front ends working with both old and new GDB's, which
>   is unfortunately a task that most front ends have to and should deal with.
>
>   2.6 Understanding the XML data
>
>   Since all commands are backwards compatible, the tree representation
>   for any XMI command can be walked the same way, no matter what version
>   of the XMI command is being used. The front end is capable of throwing
>   away any data that it does not know how or wish to process, allowing
>   it to pick and choose what data is appropriate.
>
> 3. GDB/XMI Specification
>
>   3.1 XMI Types
>
>   The XMI types are to be used for validation purposes. They can also
>   be used to tell the front end what kind of type a particular element
>   is that GDB is sending to the front end.
>
>   3.1.1 Scalar Types
>
>   <int8>      one-byte singed integer
>   <uint8>     one-byte unsigned integer
>   <int16>     two-byte signed integer
>   <uint16>    two-byte unsigned integer
>   <int32>     four-byte signed integer
>   <uint32>    four-byte unsigned integer
>   <int64>     eight-byte signed integer
>   <uint64>    eight-byte unsigned integer
>   <boolean>   0 (false) or 1 (true)
>   <string>    string
>   <float>     single-precision signed floating point number
>   <double>    double-precision signed floating point number
>
>   3.1.2 Compound Types (Structs)
>
>   A "struct" is a compound value in which accessor name is the only
>   distinction among member values, and no accessor has the same name
>   as any other.
>
>   <struct_example>
>     <element_one>one</element_one>
>     <element_two>two</element_two>
>     <element_three>three</element_three>
>   </struct_example>
>
>   A Schema for such a struct could look like this.
>
>   <element name="struct_example">
>     <complexType>
>       <element name="element_one" type="string"/>
>       <element name="element_two" type="string"/>
>       <element name="element_three" type="string"/>
>     </complexType>
>   </struct_example>
>
>   3.2 A Breakpoint Listing
>
>   3.2.1 The GDB/MI -break-list Specification
>   The -break-list Command
>
>   Displays the list of inserted breakpoints, showing the following fields:
>
>   `Number'
>     number of the breakpoint
>   `Type'
>     type of the breakpoint: `breakpoint' or `watchpoint'
>   `Disposition'
>     should the breakpoint be deleted or disabled when it is hit:
>     `keep' or `nokeep' `Enabled' is the breakpoint enabled or no:
>     `y' or `n'
>   `Address'
>     memory location at which the breakpoint is set
>   `What'
>     logical location of the breakpoint, expressed by function name,
>     file name, line number
>   `Times'
>     number of times the breakpoint has been hit
>
>   If there are no breakpoints or watchpoints, the BreakpointTable body
>   field is an empty list.
>
>   3.2.2 GDB/MI Output
>
>   -break-list
>   ^done,
>   BreakpointTable={
>     nr_rows="4",nr_cols="6",
>     hdr=[
>       {width="3",alignment="-1",col_name="number",colhdr="Num"},
>       {width="14",alignment="-1",col_name="type",colhdr="Type"},
>       {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
>       {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
>       {width="10",alignment="-1",col_name="addr",colhdr="Address"},
>       {width="40",alignment="2",col_name="what",colhdr="What"}
>     ],
>     body=[
>       bkpt={
>         number="1",type="breakpoint",disp="keep",enabled="y",
>         addr="0x0804844f",func="main",file="test.c",line="35",times="1"},
>       bkpt={
>         number="2",type="breakpoint",disp="keep",enabled="y",
>         addr="0x080483ef",func="short_func",file="test.c",line="13",times="0"},
>       bkpt={
>         number="3",type="breakpoint",disp="keep",enabled="y",
>         addr="0x0804851d",func="main",file="test.c",line="61",times="0"},
>       bkpt={
>         number="4",type="hw watchpoint",disp="keep",enabled="y",addr="",
>         what="argc",times="0"}
>       ]
>     }
>
>   3.2.3 The GDB/XMI Output
>
>   <?xml version="1.0"?>
>   <breakpoints>
>     <breakpoint>
>       <number>1</number>
>       <type>breakpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr>0x0804844f</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>35</line>
>       <times>0</times>
>     </breakpoint>
>     <breakpoint>
>       <number>2</number>
>       <type>breakpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr>0x080483ef</addr>
>       <func>short_func</func>
>       <file>test.c</file>
>       <line>13</line>
>       <times>0</times>
>     </breakpoint>
>     <breakpoint>
>       <number>3</number>
>       <type>breakpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr>0x0804851d</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>61</line>
>       <times>0</times>
>     </breakpoint>
>     <watchpoint>
>       <number>4</number>
>       <type>watchpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr></addr>
>       <what>argc</what>
>       <times>0</times>
>     </watchpoint>
>   </breakpoints>
>
>   3.3 A Backtrace
>
>   3.3.1 The GDB/MI -stack-list-frames Specification
>
>   The -stack-list-frames Command
>
>   Synopsis: -stack-list-frames [ low-frame high-frame ]
>
>   List the frames currently on the stack. For each frame it displays
>   the following info:
>
>   `level'
>     The frame number, 0 being the topmost frame,
>     i.e. the innermost function.
>   `addr'
>     The $pc value for that frame.
>   `func'
>     Function name.
>   `file'
>     File name of the source file where the function lives.
>   `line'
>     Line number corresponding to the $pc.
>
>   If invoked without arguments, this command prints a backtrace for
>   the whole stack. If given two integer arguments, it shows the frames
>   whose levels are between the two arguments (inclusive). If the two
>   arguments are equal, it shows the single frame at the corresponding level.
>
>   3.3.2 GDB/MI Output
>
>   (gdb)
>   -stack-list-frames
>   ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file="test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file="test.c",line="54"}]
>
>   ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
>   file="test.c",line="13"},frame={level="1",addr="0x080484f5",
>   func="main",file="test.c",line="54"}]
>
>   3.3.3 The GDB/XMI Output
>
>   <?xml version="1.0"?>
>   <stack>
>     <frame>
>       <level>0</level>
>       <addr>0x080483ef</addr>
>       <func>short_func</func>
>       <file>test.c</file>
>       <line>13</line>
>     </frame>
>     <frame>
>       <level>1</level>
>       <addr>0x080484f5</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>54</line>
>     </frame>
>   </stack>
>
> 4. A GDB/XMI Example
>
>   4.1 The Inferior's Code
>   #include <stdio.h>
>   int main(int argc, char **argv){
>     printf ( "newline\n" e;
>     printf ( "nonewline" );
>     return 0;
>   }
>
>   4.2 GDB/MI Output
>     (gdb)
>     -exec-run
>     ^running
>     (gdb)
>     newline
>     nonewline*stopped,reason="exited-normally"
>     (gdb)
>
>   4.3 GDB/XMI Output
>   Assuming that the escape sequence is simply \027
>   The whitespace is not necessary, and is simply there for presentation.
>
>   \027<GDB_DISPLAY_PROMPT>
>   (gdb)
>   </GDB_DISPLAY_PROMPT>\027
>   \027<GDB_WAITING_FOR_COMMAND/>\027
>   -exec-run
>   \027<GDB_INFERIOR_STARTED/>\027
>   newline
>   nonewline\027<GDB_INFERIOR_FINISHED/>\027
>   \027<GDB_DISPLAY_PROMPT>
>   gdb
>   </GDB_DISPLAY_PROMPT>\027
>   \027<GDB_WAITING_FOR_COMMAND/>\027
>
>   4.4 A Brief Description of the XMI output
>
>     4.4.1 GDB_DISPLAY_PROMPT Document
>     The front end receives the document below.
>       \027<GDB_DISPLAY_PROMPT>
>       (gdb)
>       </GDB_DISPLAY_PROMPT>\027
>     The front end sends the data to the XML processor, which then tells
>     it that the current prompt is "(gdb) ". The front end can choose to
>     do whatever it wants with this information, including display it to the
>     user, or just ignore it.
>
>     4.4.2 GDB_WAITING_FOR_COMMAND Document
>     Next, GDB transmits the document below.
>       \027<GDB_WAITING_FOR_COMMAND/>\027
>     The front end receives the data and sends it to the XML processor. The
>     processor parses the document and the front end can determine that
>     the command says that GDB is ready to accept a user command. At this
>     point, the front end understands that it is OK to transmit a command to
>     GDB.
>
>     4.4.3 The Front End Transmits a Command
>     The front end transmits the command "-exec-run".
>     Should the front end transmit commands in XML or just
>     ordinary text?
>
>     4.4.4 GDB_INFERIOR_STARTED Document
>     GDB would send a document telling the front end that the inferior
>     has begun processing.
>       \027<GDB_INFERIOR_STARTED/>\027
>     Everything the front end processes from the pipe from this point
>     until the next GDB XMI Document transmission is from the inferior.
>     It is considered to be output that the inferior would like to have
>     the user see. The front end can process this data realtime, since
>     it does not have to be sent to the XML parser for processing.
>
>     The data
>       newline
>       nonewline
>       is outputted by the inferior, and the front end processes this data
>     realtime, understanding that it is not the output of GDB.
>
>     4.4.5 GDB_INFERIOR_FINISHED Document
>     GDB would send a document telling the front end that the inferior
>     has finished processing.
>       \027<GDB_INFERIOR_FINISHED/>\027
>
>     This alerts the front end that GDB is now outputting XMI commands
>     again. The front end no longer expects information from the inferior.
>     Optionally, GDB could output a XMI command stating that a signal
>     has been caught, or some other asynchronous event has occurred. This
>     could be something like
>       \027<GDB_SIGNAL_CAUGHT>
>       <SIGNAL>
>         <NAME>SIGINT</NAME>
>         <NUMBER>2</NUMBER>
>         <COMMENT>Interrupt from keyboard</COMMENT>
>       </SIGNAL>
>       </GDB_SIGNAL_CAUGHT>\027
>     In this way, GDB could alert the front end of any asynchronous event,
>     and no special parsing mechanism will have to take place to
>     understand such actions.
>
> 5. Issues to resolve after RFC Initial approval.
>
>   5.1 If GDB will link to libxml, or just output XML
>     It would be nice if GDB was capable of sending the XML documents by
>     creating them via libxml. However, libxml2 is licensed under the
>     MIT license. Also, I don't know if libxml2 is as portable as GDB.
>
>   5.2 How the schema will represent each document sent to the front end
>     If there will be one schema for each XMI document, or a schema
>     that represents every XMI document.
>
>   5.3 Separating GDB output and the Inferior output
>     If GDB can output it's data on a different pipe than the
>     inferior then the escape sequences would not be needed to tell
>     the front end which data is from GDB and which is from the inferior.
>
>     This would simply the front end processing.
>
>   5.4 If GDB recieves commands in XML
>     If GDB links in libxml2, then it could easy receive commands from the
>     front end in XML. This would be a nice feature, although, since the
>     parser in GDB is only written once, it doesn't really matter what format
>     the commands are that is sent to it.
>

Re: GDB/XMI (XML Machine Interface)

[Michael Chastain]

Interesting idea.  Here are my opinions.  This is real armchair stuff,
I've not an MI expert, but I've had a little experience with XML
(my test bed uses XML headers to track the hundreds of configurations
that I generate and test).  So these opinions are naive.

Pro XML:

  Standard libraries are available for reading XML.  This moves one
  level of parsing out of front end code into a standard library.

  DTD helps solve the versioning problem.

Con XML:

  MI already exists.

XML standardizes some of the lowest levels of the data interchange format.
But I get the impression that the problems you have are not at that level.
They are really one level up.  Problems like:

. The MI has an insufficient reflective interface.  That is, the front end
  cannot query GDB and find out the list of supported commands and the
  format of each command.  With XML, gdb could support commands to get
  the list of supported commands and a DTD for each command.

. MI output changes from time to time.  Your proposal is to restrict
  the changes: fields can be added but not removed or modified;
  commands can be added and old commands deprecated.  I think this
  sort of protocol evolution is XML-neutral, it's the same kind of
  restrictions whatever the data format.

. Inferior process output mixes with gdb output.  I don't think XML
  helps with this at all -- it's a problem at a lower level than the
  XML level.  Either open several streams, or emit some kind of packets
  on the single stream, with each packet tagged as "gdb output" or
  "inferior output".  XML is not very good for interpolating
  "inferior output" at random places in the XML stream.

From a higher view, adopting XML would force us to think about these
issues.  If a program writes XML then it's natural to expect the XML to
match some DTD, and then you start thinking about versioning the DTD,
and so on.  It's a cultural environment where the requirements that come
from the front end are a natural part of this environment.

As far as I can tell, and I'm no expert on MI, we could do most of these
things with the existing MI interface.  Separating inferior output from
gdb output is a different kind of problem, no matter what the data
interchange format.  But the reflective interface and the protocol
evolution could be done with MI.

We could identify the requirements and then make MI meet those
requirements, without going to XML data interchange format.  Or,
conversely, if we're having trouble with MI fields changing too much in
cvs gdb, then we're also at risk from the DTD changing too much in an
XML-based MI.

Michael C

Re: GDB/XMI (XML Machine Interface)

[Chris Friesen]

Hi Bob,

  	I'm not defending MI, I just haven't had any problems parsing MI  
output, mi0 or mi1, using Apple's branch of gdb. The structure is well  
defined and if you parse the payload into arrays and dictionaries then  
it's not so bad to deal with.

	The versioning problem you mention is solved by having a specification  
for backward compatibility and not by any inherent virtue of XML. (We  
could just add a version field to MI output...FYI: Apple's branch has  
an MI verify command to test for support of MI commands.) So I'm not  
sure what XML delivers for MI other than people can use a 'standard'  
parser. I guess the DTD's are a nice place for the spec of the MI  
commands and there are tools to help validate against them, so that's a  
win. (The code is *not* the spec people...)

> From: Bob Rossi <bob@brasko.net>
> Date: August 10, 2004 1:14:40 PM PDT
> To: gdb@sources.redhat.com
> Subject: GDB/XMI (XML Machine Interface)
>
> Hi,
>
> As most of you know, I have been writing a front end to GDB called  
> CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I

>
>   1.2 The Objective
>
>   The objective of GDB/XMI is to create a reliable protocol between
>   GDB and the front end controlling GDB.

Is MI not reliable? Reliable is good.
>
> 2. The GDB/XMI Overview
>
>   2.1 Passing Information between GDB and the front end
>
>   All information passed between GDB and the front end is done in
>   the form of an XML document. Each XMI command, generates an XML
>   document, and is sent from GDB to the front end.
>

This would not be good for MI commands *to* gdb as developers of MI  
commands often enter them by hand.

>
>   2.5 Version Management
>
>   This model keeps front ends working with both old and new GDB's,  
> which
>   is unfortunately a task that most front ends have to and should deal  
> with.
>

I don't see a new IDE supporting an old GDB, it might with minimum  
version numbers for the MI commands, but the new IDE isn't going to  
support a deprecated command if they choose to use the new MI command.  
The IDE is going to choose features over using an old version of GDB.  
Backward compatibility of MI commands will make it so my old IDE can  
use a new GDB, which is more important.

>   3.3.2 GDB/MI Output
>
>   (gdb)
>   -stack-list-frames
>    
> ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file= 
> "test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file 
> ="test.c",line="54"}]
>
>   ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
>   file="test.c",line="13"},frame={level="1",addr="0x080484f5",
>   func="main",file="test.c",line="54"}]
>
>   3.3.3 The GDB/XMI Output
>
>   <?xml version="1.0"?>
>   <stack>
>     <frame>
>       <level>0</level>
>       <addr>0x080483ef</addr>
>       <func>short_func</func>
>       <file>test.c</file>
>       <line>13</line>
>     </frame>
>     <frame>
>       <level>1</level>
>       <addr>0x080484f5</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>54</line>
>     </frame>
>   </stack>
>

<snip>

Hate to say this but the MI output is more human readable for 'key' and  
'value' (good for debugging) while the the XML is not friendly to my  
scanning... the MI reads more like code. If you look at it, the MI has  
the same tree structure as the XML, just written in a less pedantic  
form. An MI to XML formatter/converter wouldn't be that hard.

Overall MI suffers most from not having a specification for the various  
commands, as well as not documenting which platforms the commands are  
supported on. I don't see a big benefit from using XML. It could be  
tested by writing a simple MI to XML converter without having to make a  
lot of changes to gdb.

Cheers,
-ChrisF

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Chris Friesen <gdb001@speakeasy.net>:
> (The code is *not* the spec people...)

code is usually less ambiguous than specs.  it's not clear to me
that there's much point in making a spec for something that's
likely to have only one implementation that will always have
public source code.  well, isolating it as a spec should make
some things easier, like the versioning issue.

I wish the world had settled on something other than XML.  it's a
lot harder to use than, say, LISP syntax, and libxml2 is about as
much code as a Common LISP implementation.  oh well.
--

Re: GDB/XMI (XML Machine Interface)

[Fabian Cenedese]

>                      GDB/XMI (XML Machine Interface)
>
>  3.2.1 The GDB/MI -break-list Specification
>  The -break-list Command
>
>  Displays the list of inserted breakpoints, showing the following fields:
>
>  `Number'
>    number of the breakpoint 
>  `Type'
>    type of the breakpoint: `breakpoint' or `watchpoint' 
>  `Disposition'
>    should the breakpoint be deleted or disabled when it is hit: 
>    `keep' or `nokeep' `Enabled' is the breakpoint enabled or no: 
>    `y' or `n' 
>  `Address'
>    memory location at which the breakpoint is set 
>  `What'
>    logical location of the breakpoint, expressed by function name, 
>    file name, line number 
>  `Times'
>    number of times the breakpoint has been hit 
>
>  If there are no breakpoints or watchpoints, the BreakpointTable body 
>  field is an empty list. 

I think there should be an additional field for the task id, indicating if it's
a general breakpoint (id=-1 or so) or a task-specific breakpoint.

bye  Fabi

Re: GDB/XMI (XML Machine Interface)

[Chris Friesen]

The code is an implementation that doesn't convey the objectives or 
intent. Is that behavior a bug or feature in the code? It can be 
difficult to tell if there is not a description of what the code is 
supposed to do. The specification can set the objectives and intentions 
that define the bounds of the implementation, act as guidance for 
testing and other development. This is easier to do in writing than 
with code. A specification can be as specific or ambiguous as the 
writer desires, it's a balancing act depending on your needs.

Happy spec writing,
-ChrisF

On Aug 10, 2004, at 11:28 PM, Felix Lee wrote:

> Chris Friesen <gdb001@speakeasy.net>:
>> (The code is *not* the spec people...)
>
> code is usually less ambiguous than specs.  it's not clear to me
> that there's much point in making a spec for something that's
> likely to have only one implementation that will always have
> public source code.  well, isolating it as a spec should make
> some things easier, like the versioning issue.
>

Re: GDB/XMI (XML Machine Interface)

[Nick NoSpam]

First I'd like to commend you on the initiative to do something about
the MI problems.  I too have fiddled w/ a frontend and aun into a slew
of problems w/ MI2 (some of which made their way into the bug tracker
months ago w/out any attention).  I also have a great deal of experience
w/ XML (have used it for years and continue to do so at my job).

Now for the real honesty:  I don't think an XML interface is going to
fix the real problem.

Disclaimer:  I'm not an expert at GDB (it's internals nor usage) or GDB
MI.  The following is my candid opinion--it's too late (technically
early) to be tactful.

The real problem is that GDB is not a library.  It's a fairly convoluted
mess that uses the console as it's primary interface.  That is wrong. 
All abstractions and extensions (including MI*) work through the
console--essentially automating a user's keystrokes.  And there lies the
fundamental problem:  all methods of offering more than the console
interface are subject to the pitfalls of a console interface.  Michael
Chastain points out a popular one:  distinguishing GDB output from
inferior output.
What's worse, GDB has been massaged over time to be a one-size-fits-all
solution (ie. tightly coupled).  That's also wrong.  The problems of
which are evident when one tries to add or modify significant
functionality.

The time spent to generate a well-defined XML interface won't provide
much more than spending the same time improving the MI2 interface
(perhaps yielding MI3).  But neither of these approaches solves the real
problem outlined above.

So I think the best (and proper) thing to do is work on splitting GDB
into a separate, well-defined library.  Then, all interfaces (including
the console) are simply clients to this library.  At that time, an XML
interface would go further (as it adds language independence and
remoting).

A quick google search tells me I'm not the only one w/ this idea.  I
don't necessarily agree w/ the design of Andrew Cagney's libGDB, but the
idea is spot on:
http://sources.redhat.com/gdb/papers/libgdb2/

Regards,
Nick G.


On Tue, 2004-08-10 at 16:14, Bob Rossi wrote:
> Hi,
> 
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
> 
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
> 
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to 
> sit on top of GDB. This will at least give the community one open 
> source front end to GDB and an example to prove that the new 
> machine interface works.
> 
> I can't wait to hear your opinions/comments.
> 
> Thanks,
> Bob Rossi
> 
>                        GDB/XMI (XML Machine Interface)
> 
>                                Robert Rossi
>                                August 2004
>                                bob@brasko.net
> 
> 
>                              TABLE OF CONTENTS
> 
> 1. Introduction
>   1.1 The Problem
>   1.2 The Objective
> 
> 2. The GDB/XMI Overview
>   2.1 Passing Information between GDB and the front end
>   2.2 Parsing XMI Commands from GDB's output
>   2.3 Parsing the Inferior's output
>   2.4 Validation
>   2.5 Version Management
>   2.6 Understanding the XML data
> 
> 3. GDB/XMI Specification
>   3.1 XMI Types
>     3.1.1 Scalar Types
>     3.1.2 Compound Types (Structs)
>   3.2 A Breakpoint Listing
>     3.2.1 The GDB/MI -break-list Specification
>     3.2.2 GDB/MI Output
>     3.2.3 The GDB/XMI Output
>   3.3 A Backtrace
>     3.3.1 The GDB/MI -stack-list-frames Specification
>     3.3.2 GDB/MI Output
>     3.3.3 The GDB/XMI Output
> 
> 4. A GDB/XMI Example
>   4.1 The Inferior's Code
>   4.2 GDB/MI Output
>   4.3 GDB/XMI Output
>   4.4 A Brief Description of the XMI output
>     4.4.1 GDB_DISPLAY_PROMPT Document
>     4.4.2 GDB_WAITING_FOR_COMMAND Document
>     4.4.3 The Front End Transmits a Command
>     4.4.4 GDB_INFERIOR_STARTED Document
>     4.4.5 GDB_INFERIOR_FINISHED Document
> 
> 5. Issues to resolve after RFC Initial approval.
>   5.1 If GDB will link to libxml, or just output XML
>   5.2 How the schema will represent each document sent to the front end
>   5.3 Separating GDB output and the Inferior output 
>   5.4 If GDB recieves commands in XML
> 
> Preface
> 
>   GDB/XMI is meant to be the successor of GDB/MI. It improves upon the
>   idea of GDB/MI and fixes many of the known issues that GDB/MI contains.
> 
> 1. Introduction
>   1.1 The Problem
> 
>   Writing a front end for GDB/MI means that a front end has to be able to
>   implement an ad hoc parser, capable of understanding all of the data 
>   sent from GDB to it. For each version of GDB, functionality might change, 
>   without ever allowing the GUI to understand what the interface differences
>   are in a scientific manner. Any guessing from version to version is a 
>   best-chance scenario, leaving the front end guessing what functionality
>   a CVS snapshot has that has been installed on any particular distribution.
> 
>   1.2 The Objective
> 
>   The objective of GDB/XMI is to create a reliable protocol between
>   GDB and the front end controlling GDB. A goal of this project is to
>   remove most of the parsing from the front end, and move it to a
>   reliable parsing library, capable of validating the data it is 
>   parsing, and building a tree representation of the data without 
>   any front end infrastructure. It is believed that the protocol between 
>   GDB and any front end can be automated in every front end and that it 
>   is not necessary to have any front end developer worry about the syntax
>   or grammar of the actual commands sent between GDB and the front end.
> 
>   Another goal of this project is to formalize the maintenance and
>   version management of the XMI commands, as GDB matures, and modifies the
>   XMI commands over time. The front end should be independent of the
>   XMI command versions, and should be able to determine what data is
>   available to it, without worrying about the version of any particular
>   XMI command.
>  
>   It is believed this can help front end writers in several ways. First,
>   there will be a significant reduction of time spent in parsing the 
>   obscure MI commands, and understanding what the output represents.
>   This gives front end developers a greater chance of actually getting
>   to 1.0 on any given front end, and allowing for much more time to 
>   be spent on the look & feel of the front end, not including the much
>   needed features that most front ends do not have. Secondly, It will
>   reduce the code size of each front end, potentially reducing the number 
>   of bugs, and allowing for a more reliable set of front ends that sit 
>   on top of GDB. 
> 
> 2. The GDB/XMI Overview
> 
>   GDB/XMI is based mostly on the model of GDB/MI. The major differences 
>   are the need to pass the information from GDB to the front end via XML
>   documents and the ability to give the front end a schema, capable 
>   of validating an XMI command.
> 
>   2.1 Passing Information between GDB and the front end
> 
>   All information passed between GDB and the front end is done in
>   the form of an XML document. Each XMI command, generates an XML
>   document, and is sent from GDB to the front end.
> 
>   2.2 Parsing XMI Commands from GDB's output
> 
>   XMI is the protocol between GDB and the front end. It is an XML
>   based Markup Language that is intended to be the Machine Interface
>   between GDB and any application that would like to communicate with it.
>   
>   An XML document is started and stopped with escape sequences. These
>   sequences tell the front end when an XML document is being sent, and
>   when the XML document is done being sent. For each XMI command, GDB 
>   will output an escape sequence saying that it is ready to transmit
>   the XML Document response. Then it will output the XML Document. Finally,
>   GDB will transmit another escape sequence, saying that the document 
>   has been completed. This allows the front end to understand what 
>   information to pass to the XML parser, and what information is output
>   from the inferior.
> 
>   2.3 Parsing the Inferior's output
>   
>   When the GDB sends the XML command stating that the inferior has started, 
>   the front end can then parse the output of GDB waiting for an escape
>   sequence, saying that the inferior has stopped running. All of the 
>   data captured between these two points are output from the inferior.
>   It can be processed real time and sent to the user to update them of what 
>   the inferior is doing. Any asynchronous commands can of course break the
>   stream and output data to the front end, and then notify the front end
>   that the inferior has started again. This easily allows the front end
>   to understand what data is from GDB and what data is from the inferior.
>   The only downside to this design is that escape sequences are needed.
>   However, the only way to change that is to allow the inferior's output
>   to be on a separate communication link (pipe) than the output of GDB.
>   So far, this has not happened. Section 5, point 3 illustrates that it
>   would be desirable to split GDB's and the inferior's output up, this
>   would cause the protocol between GDB and the front end to not include
>   the escape sequences before and after each XMI document sent.
> 
>   2.4 Validation
>   The validation document (DTD) has to be up to date with the XMI 
>   command for the particular version of GDB. Also, this document has to
>   be in one place. Therefore, I propose, that an XMI command be given to
>   output to the front end all of the XMI validation documents (DTD?) or
>   pass a parameter to have GDB output the validation document for a 
>   particular XMI command. This document will prove that the XMI commands
>   are valid, and GDB is not misbehaving. Front end writers can report
>   bad output from GDB easily, and the development process can self-adjust.
> 
>   The main goal of this tactic is that GDB is capable of telling front ends
>   if the output it is generating is correct. Front ends can use this 
>   capability, at virtually no extra cost, to determine if the protocol
>   between the two processes is incorrect. By allowing GDB to keep the 
>   Schema's, the DRY principle is honored, and things will not get out of
>   date.
> 
>   2.5 Version Management
> 
>   From version to version, XMI commands will be modified. Commands will
>   be fully backwards compatible, from version to version, allowing only
>   fields to be added, or providing more information than is already 
>   there. The front ends will not have to be updated in this way, 
>   allowing existing front ends to always be able to use at least the 
>   amount of information that they have been programmed to understand.
> 
>   Since it is not a perfect world, it is not always possible to make 
>   XMI commands backwards compatible. In this case, the XMI command to
>   be replaced will be marked as deprecated and a new XMI command will
>   be generated to take it's place. This new command will force the 
>   front end writer to program the functionality of the new command into
>   there program, and from then on, will again have a front end capable
>   of parsing the new command with a new GDB, and the old command with 
>   the old GDB.
> 
>   This model keeps front ends working with both old and new GDB's, which
>   is unfortunately a task that most front ends have to and should deal with.
> 
>   2.6 Understanding the XML data
> 
>   Since all commands are backwards compatible, the tree representation
>   for any XMI command can be walked the same way, no matter what version
>   of the XMI command is being used. The front end is capable of throwing
>   away any data that it does not know how or wish to process, allowing
>   it to pick and choose what data is appropriate.
> 
> 3. GDB/XMI Specification
> 
>   3.1 XMI Types
> 
>   The XMI types are to be used for validation purposes. They can also
>   be used to tell the front end what kind of type a particular element
>   is that GDB is sending to the front end.
> 
>   3.1.1 Scalar Types
> 
>   <int8>      one-byte singed integer
>   <uint8>     one-byte unsigned integer
>   <int16>     two-byte signed integer
>   <uint16>    two-byte unsigned integer
>   <int32>     four-byte signed integer
>   <uint32>    four-byte unsigned integer
>   <int64>     eight-byte signed integer
>   <uint64>    eight-byte unsigned integer
>   <boolean>   0 (false) or 1 (true)
>   <string>    string
>   <float>     single-precision signed floating point number
>   <double>    double-precision signed floating point number
> 
>   3.1.2 Compound Types (Structs)
> 
>   A "struct" is a compound value in which accessor name is the only 
>   distinction among member values, and no accessor has the same name 
>   as any other.
> 
>   <struct_example>
>     <element_one>one</element_one>
>     <element_two>two</element_two>
>     <element_three>three</element_three>
>   </struct_example>
> 
>   A Schema for such a struct could look like this.
> 
>   <element name="struct_example">
>     <complexType>
>       <element name="element_one" type="string"/>
>       <element name="element_two" type="string"/>
>       <element name="element_three" type="string"/>
>     </complexType>
>   </struct_example>
> 
>   3.2 A Breakpoint Listing
> 
>   3.2.1 The GDB/MI -break-list Specification
>   The -break-list Command
> 
>   Displays the list of inserted breakpoints, showing the following fields:
> 
>   `Number'
>     number of the breakpoint 
>   `Type'
>     type of the breakpoint: `breakpoint' or `watchpoint' 
>   `Disposition'
>     should the breakpoint be deleted or disabled when it is hit: 
>     `keep' or `nokeep' `Enabled' is the breakpoint enabled or no: 
>     `y' or `n' 
>   `Address'
>     memory location at which the breakpoint is set 
>   `What'
>     logical location of the breakpoint, expressed by function name, 
>     file name, line number 
>   `Times'
>     number of times the breakpoint has been hit 
> 
>   If there are no breakpoints or watchpoints, the BreakpointTable body 
>   field is an empty list. 
> 
>   3.2.2 GDB/MI Output
> 
>   -break-list
>   ^done,
>   BreakpointTable={
>     nr_rows="4",nr_cols="6",
>     hdr=[
>       {width="3",alignment="-1",col_name="number",colhdr="Num"},
>       {width="14",alignment="-1",col_name="type",colhdr="Type"},
>       {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
>       {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
>       {width="10",alignment="-1",col_name="addr",colhdr="Address"},
>       {width="40",alignment="2",col_name="what",colhdr="What"}
>     ],
>     body=[
>       bkpt={
>         number="1",type="breakpoint",disp="keep",enabled="y",
>         addr="0x0804844f",func="main",file="test.c",line="35",times="1"},
>       bkpt={
>         number="2",type="breakpoint",disp="keep",enabled="y",
>         addr="0x080483ef",func="short_func",file="test.c",line="13",times="0"},
>       bkpt={
>         number="3",type="breakpoint",disp="keep",enabled="y",
>         addr="0x0804851d",func="main",file="test.c",line="61",times="0"},
>       bkpt={
>         number="4",type="hw watchpoint",disp="keep",enabled="y",addr="",
>         what="argc",times="0"}
>       ]
>     }
> 
>   3.2.3 The GDB/XMI Output
> 
>   <?xml version="1.0"?>
>   <breakpoints>
>     <breakpoint>
>       <number>1</number>
>       <type>breakpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr>0x0804844f</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>35</line>
>       <times>0</times>
>     </breakpoint>
>     <breakpoint>
>       <number>2</number>
>       <type>breakpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr>0x080483ef</addr>
>       <func>short_func</func>
>       <file>test.c</file>
>       <line>13</line>
>       <times>0</times>
>     </breakpoint>
>     <breakpoint>
>       <number>3</number>
>       <type>breakpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr>0x0804851d</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>61</line>
>       <times>0</times>
>     </breakpoint>
>     <watchpoint>
>       <number>4</number>
>       <type>watchpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr></addr>
>       <what>argc</what>
>       <times>0</times>
>     </watchpoint>
>   </breakpoints>
> 
>   3.3 A Backtrace
> 
>   3.3.1 The GDB/MI -stack-list-frames Specification
> 
>   The -stack-list-frames Command
> 
>   Synopsis: -stack-list-frames [ low-frame high-frame ]
> 
>   List the frames currently on the stack. For each frame it displays 
>   the following info:
> 
>   `level'
>     The frame number, 0 being the topmost frame, 
>     i.e. the innermost function. 
>   `addr'
>     The $pc value for that frame. 
>   `func'
>     Function name. 
>   `file'
>     File name of the source file where the function lives. 
>   `line'
>     Line number corresponding to the $pc. 
> 
>   If invoked without arguments, this command prints a backtrace for 
>   the whole stack. If given two integer arguments, it shows the frames 
>   whose levels are between the two arguments (inclusive). If the two 
>   arguments are equal, it shows the single frame at the corresponding level. 
> 
>   3.3.2 GDB/MI Output
> 
>   (gdb)
>   -stack-list-frames
>   ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file="test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file="test.c",line="54"}]
> 
>   ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
>   file="test.c",line="13"},frame={level="1",addr="0x080484f5",
>   func="main",file="test.c",line="54"}]
> 
>   3.3.3 The GDB/XMI Output
>     
>   <?xml version="1.0"?>
>   <stack>
>     <frame>
>       <level>0</level>
>       <addr>0x080483ef</addr>
>       <func>short_func</func>
>       <file>test.c</file>
>       <line>13</line>
>     </frame>
>     <frame>
>       <level>1</level>
>       <addr>0x080484f5</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>54</line>
>     </frame>
>   </stack>
> 
> 4. A GDB/XMI Example
>   
>   4.1 The Inferior's Code
>   #include <stdio.h>
>   int main(int argc, char **argv){
>     printf ( "newline\n" e;
>     printf ( "nonewline" );
>     return 0;
>   }
> 
>   4.2 GDB/MI Output
>     (gdb)
>     -exec-run
>     ^running
>     (gdb)
>     newline
>     nonewline*stopped,reason="exited-normally"
>     (gdb)
> 
>   4.3 GDB/XMI Output
>   Assuming that the escape sequence is simply \027
>   The whitespace is not necessary, and is simply there for presentation.
> 
>   \027<GDB_DISPLAY_PROMPT>
>   (gdb) 
>   </GDB_DISPLAY_PROMPT>\027
>   \027<GDB_WAITING_FOR_COMMAND/>\027
>   -exec-run
>   \027<GDB_INFERIOR_STARTED/>\027
>   newline
>   nonewline\027<GDB_INFERIOR_FINISHED/>\027
>   \027<GDB_DISPLAY_PROMPT>
>   gdb
>   </GDB_DISPLAY_PROMPT>\027
>   \027<GDB_WAITING_FOR_COMMAND/>\027
> 
>   4.4 A Brief Description of the XMI output
>   
>     4.4.1 GDB_DISPLAY_PROMPT Document
>     The front end receives the document below.
>       \027<GDB_DISPLAY_PROMPT>
>       (gdb) 
>       </GDB_DISPLAY_PROMPT>\027
>     The front end sends the data to the XML processor, which then tells
>     it that the current prompt is "(gdb) ". The front end can choose to
>     do whatever it wants with this information, including display it to the
>     user, or just ignore it.
> 
>     4.4.2 GDB_WAITING_FOR_COMMAND Document
>     Next, GDB transmits the document below.
>       \027<GDB_WAITING_FOR_COMMAND/>\027
>     The front end receives the data and sends it to the XML processor. The
>     processor parses the document and the front end can determine that 
>     the command says that GDB is ready to accept a user command. At this
>     point, the front end understands that it is OK to transmit a command to
>     GDB.
> 
>     4.4.3 The Front End Transmits a Command
>     The front end transmits the command "-exec-run".
>     Should the front end transmit commands in XML or just 
>     ordinary text?
> 
>     4.4.4 GDB_INFERIOR_STARTED Document
>     GDB would send a document telling the front end that the inferior
>     has begun processing.
>       \027<GDB_INFERIOR_STARTED/>\027
>     Everything the front end processes from the pipe from this point 
>     until the next GDB XMI Document transmission is from the inferior.
>     It is considered to be output that the inferior would like to have
>     the user see. The front end can process this data realtime, since
>     it does not have to be sent to the XML parser for processing.
> 
>     The data
>       newline
>       nonewline
>       is outputted by the inferior, and the front end processes this data
>     realtime, understanding that it is not the output of GDB.
> 
>     4.4.5 GDB_INFERIOR_FINISHED Document
>     GDB would send a document telling the front end that the inferior
>     has finished processing.
>       \027<GDB_INFERIOR_FINISHED/>\027
> 
>     This alerts the front end that GDB is now outputting XMI commands
>     again. The front end no longer expects information from the inferior.
>     Optionally, GDB could output a XMI command stating that a signal 
>     has been caught, or some other asynchronous event has occurred. This
>     could be something like
>       \027<GDB_SIGNAL_CAUGHT>
>       <SIGNAL>
>         <NAME>SIGINT</NAME>
>         <NUMBER>2</NUMBER>
>         <COMMENT>Interrupt from keyboard</COMMENT>
>       </SIGNAL>
>       </GDB_SIGNAL_CAUGHT>\027
>     In this way, GDB could alert the front end of any asynchronous event,
>     and no special parsing mechanism will have to take place to 
>     understand such actions.
> 
> 5. Issues to resolve after RFC Initial approval.
> 
>   5.1 If GDB will link to libxml, or just output XML
>     It would be nice if GDB was capable of sending the XML documents by
>     creating them via libxml. However, libxml2 is licensed under the
>     MIT license. Also, I don't know if libxml2 is as portable as GDB.
> 
>   5.2 How the schema will represent each document sent to the front end
>     If there will be one schema for each XMI document, or a schema
>     that represents every XMI document.
> 
>   5.3 Separating GDB output and the Inferior output 
>     If GDB can output it's data on a different pipe than the 
>     inferior then the escape sequences would not be needed to tell
>     the front end which data is from GDB and which is from the inferior.
> 
>     This would simply the front end processing.
> 
>   5.4 If GDB recieves commands in XML
>     If GDB links in libxml2, then it could easy receive commands from the
>     front end in XML. This would be a nice feature, although, since the
>     parser in GDB is only written once, it doesn't really matter what format 
>     the commands are that is sent to it.

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

Hi,

Thanks to everyone that has looked at this RFC so far. I will leave the idea
floating around for a few days to let everyone have a chance to
respond. Then I will follow up the RFC with a summary of everyone's
opinions.

I can see with the ideas given already, that if everyone contributes 
(at least informationally), this RFC could be modified to fit into GDB
very nicely.

Thanks,
Bob Rossi


On Tue, Aug 10, 2004 at 04:14:40PM -0400, Bob Rossi wrote:
> Hi,
> 
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
> 
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
> 
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to 
> sit on top of GDB. This will at least give the community one open 
> source front end to GDB and an example to prove that the new 
> machine interface works.
> 
> I can't wait to hear your opinions/comments.
> 
> Thanks,
> Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Alain Magloire]

> 
> Hi,
> 
> Thanks to everyone that has looked at this RFC so far. I will leave the idea
> floating around for a few days to let everyone have a chance to
> respond. Then I will follow up the RFC with a summary of everyone's
> opinions.
> 
> I can see with the ideas given already, that if everyone contributes 
> (at least informationally), this RFC could be modified to fit into GDB
> very nicely.
> 

Nick "No spam" G. and other said something about this already .. I'll just reiterate.

The problem is not so much MI as a protocol then the implementation of MI in gdb 8-).
If you read the MI spec, it is not that bad .. actually very promising
and with the proposed changes from Andrew C and crew .. not bad at all.

MI did offer a consistent parsing vs protocol like Annoted {1,2}

Reality check, it hits you like a brick wall: the grand canyon between the documentation
vs actual implementation.
(some third parties like WindRiver or Apple seems to have "cleaner" implementation of MI).

Doing a clean recursive decent parser for MI, is actually very simple... 
it's just that you have to make n exceptions: inconsitencies, plain bugs,
crap etc .. the inferior output can be intertwine to the protocol, the duality CLI vs MI in an IDE,
the OOB(async notifications) being incomplete, the inconsistensies between argument parsing etc ..

Pros:
No doubt, XMI will offer an even more consistent parsing, it is a well know and formal language.
So the parsing will no longer be the focus (with all the available xml parsers) of problems.
The focus will be shift to more consistency of the data and folks can concentrate on
real issues(can we get notification for loading of dll or catch event implementation 8-) etc .. a good thing.

But whether XMI or MI the problems remains; a good implementation and resources to work on it.
GDB carries in its belly an enormous knowledge an heritage but that makes it also obese 8-(
most folks prefer to go around problems with yet another rewrite instead of digging in ...
Question: are you doing the same with this XMI proposal ? If yes you'll fall to the same trap
as MI and GDB will carry "yet another incomplete implementation" 8-)

Note:
don't get me wrong the RFC is pretty good, and for a Java programer, xml is pure symphony.

Re: GDB/XMI (XML Machine Interface)

[Jason Molenda]

Hi Alain,

On Aug 11, 2004, at 12:26 PM, Alain Magloire wrote:

> Doing a clean recursive decent parser for MI, is actually very 
> simple...
> it's just that you have to make n exceptions: inconsitencies, plain 
> bugs,
> crap etc .. the inferior output can be intertwine to the protocol, the 
> duality CLI vs MI in an IDE, the OOB(async notifications) being 
> incomplete, the inconsistensies between argument parsing etc ..


I think both Chris and Jim mentioned this already, but it's easy to 
separate inferior I/O from the MI command stream.  The UI sets up a 
pseudo tty that it controls and uses the gdb "tty" command to redirect 
inferior I/O to that ptty.  Our Xcode UI has been using this technique 
for at least a couple of years now.

Jason

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Chris Friesen <gdb001@speakeasy.net>:
> The code is an implementation that doesn't convey the objectives or 
> intent. Is that behavior a bug or feature in the code?

if a programmer isn't going to explain it in the code, why expect
them to explain it in a spec?  having a separate spec is like
removing comments from the source and putting them in a different
file, which introduces maintenance problems.  there's more chance
of code and description being in sync if they're "near" each
other, and extraction can be automated.

well, a spec is probably more closely related to testcases than
to implementation.  so perhaps in an ideal world, an interface
would be a single document that's easy to read, easy to parse,
and easy to test against.

(it's not clear to me that an xml dtd is any of those attributes,
but I don't have a strong objection to it.)
--

OT: Re: GDB/XMI (XML Machine Interface)

[Chris Friesen]

On Aug 11, 2004, at 3:43 PM, Felix Lee wrote:

> Chris Friesen <gdb001@speakeasy.net>:
>> The code is an implementation that doesn't convey the objectives or
>> intent. Is that behavior a bug or feature in the code?
>
> if a programmer isn't going to explain it in the code, why expect
> them to explain it in a spec?  having a separate spec is like
> removing comments from the source and putting them in a different

In many cases the code comments are not the equivalent of a plan or 
design. If they are, then that's great. It's not a specification 
because of where it lives, it is a specification by what it tells you 
of the design and objectives. A programming language doesn't do well 
communicating a guiding design. English isn't suited for programming a 
computer. Thus 'the code is not the spec'. When compilers operate on 
comments, I'll start calling comments code.

Most people don't draw up architectural blueprints to build a dog 
house, they might use a pencil sketch. You could build a house without 
blueprints, but would you build a sky-scraper without them? Your 
specification should fit the project at hand, be it code comments, XMI 
specification proposal, sketches or blueprints.

A specification is as much a design process as it is a document, a tool 
that you size and use to fit your needs.

Cheers,
- Chris

Re: GDB/XMI (XML Machine Interface)

[Nick NoSpam]

> it's easy to separate inferior I/O from the MI command stream.
Certainly there are methods, but the MI2 spec clearly defines how this
situation should be handled.  Apparently this is not a new issue, so
when MI2 was defined, inferior output was specifically handled via it's
own syntax.  So the problem is implementation (see bug 1654 from May). 
XML format won't cure this situation.

Regards,
Nick G.

On Wed, 2004-08-11 at 18:35, Jason Molenda wrote:
> Hi Alain,
> 
> On Aug 11, 2004, at 12:26 PM, Alain Magloire wrote:
> 
> > Doing a clean recursive decent parser for MI, is actually very 
> > simple...
> > it's just that you have to make n exceptions: inconsitencies, plain 
> > bugs,
> > crap etc .. the inferior output can be intertwine to the protocol, the 
> > duality CLI vs MI in an IDE, the OOB(async notifications) being 
> > incomplete, the inconsistensies between argument parsing etc ..
> 
> 
> I think both Chris and Jim mentioned this already, but it's easy to 
> separate inferior I/O from the MI command stream.  The UI sets up a 
> pseudo tty that it controls and uses the gdb "tty" command to redirect 
> inferior I/O to that ptty.  Our Xcode UI has been using this technique 
> for at least a couple of years now.
> 
> Jason

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Tue, Aug 10, 2004 at 04:14:40PM -0400, Bob Rossi wrote:
> Hi,
> 
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
> 
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
> 
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to 
> sit on top of GDB. This will at least give the community one open 
> source front end to GDB and an example to prove that the new 
> machine interface works.
> 
> I can't wait to hear your opinions/comments.

Hi,

Well, it seems as if my efforts only brought up enough interest to just 
get a couple of replies. 

Basically, most of you point out that I am interested in changing at a high 
level the development process of the interface between GDB and the front end.
Obviously, switching GDB's output to XML only gains the front ends a simple
way to parse the data. Besides validation, and maybe transformations, it 
basically does nothing else. I have listed some other higher level things, like 
Michael pointed out. These are the things that I feel will make my front end 
successful over the long run. I understand that what makes my front end 
successful might not make everyone's successful, but the union of all these
ideas will make everyone's front end successful. Therefor, I am offering up
at least the minimum amount of work that needs to be done to GDB in order to
make a front end successful, not just now, but in the future also.

   Michael noted some of the things I think a protocol should contain
   . The MI has an insufficient reflective interface.  
   . MI output changes from time to time.  Your proposal is to restrict
     the changes: fields can be added but not removed or modified;
     commands can be added and old commands deprecated.  
   . Inferior process output mixes with gdb output.

All of these issues are key to what I think a front end should expect from
GDB. However, I realize that none of these issues have anything to do with
XML. XML is just an obvious way to communicate data between to entities.

Jim suggested, 
   1) You can run gdb and use the tty command to send inferior output to a 
separate pty.  
   2) The XML output should just be another ui_out.  

   and some suggestions on commands sent from the front end to GDB.

Nick G suggested,
   Now for the real honesty:  I don't think an XML interface is going to
   fix the real problem.  The real problem is that GDB is not a library. 

Chris F suggested,
   He defiantly didn't see the benefit to switching to XMI, since XML is harder
   for him to understand than MI output.

I don't really know where to go from here. The XML change I think is a no brainer. 
It is a task that every front end writer in the future will be thankful for. Believe me,
no one is interested in parsing the MI output. It is a *complete waste of time*.
Next and more importantly, the versioning is a major hurdle for me in regards to MI. 
I think protocols should always be backwards compatible, it is a necessity for the 
client of the protocol. However, up till now I might be the only one making a big stink 
out of this, and therefor the versions are not backwards compatible. I believe CVS
snapshots and major releases should always adhere to the backwards compatibility test.
For example, I use CGDB with a version of GNAT's GDB and it works because A2 hasn't 
changed. I want to be able to use XMI with a 4 year old GDB, because the software world
is majorly screwed up, and sometimes I find myself having to work with ancient software.

If this document could be modified in any way, I would be more than glad to make an
initial effort at getting GDB/XMI going. I believe that all of the infrastructure for
the MI commands can stay in place, and like Jim said, a new ui_out  could be created.
A re-write from the MI is the worst idea in my opinion. I think that GDB is finally 
maturing a protocol that front end developers can not snicker at. I believe it should just
be modified in some ways and that XML would be a great plus for outputting data.

Finally, the difference between a text based protocol and a libgdb interface is irrelevant
to me. I would personally prefer the text based protocol at this point in time seeing that
there is no libgdb. What stopped the production of that effort? Also, making clients link
to the GDB they want to work with seems like a pain.

My proposal would be to make all of the infrastructure change to the MI code, not new code. 
Add validation, versioning, and maybe a new way besides the tty command to separate 
GDB output and the inferior output. Finally, add a new ui_out that outputs the commands in
XML. Thus, only adding the XML feature completely, otherwise, changing the process's of the 
MI to work the way I am suggesting.

Eagerly awaiting instructions :)

Thanks,
Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Chris Friesen]

On Aug 19, 2004, at 4:49 PM, Bob Rossi wrote:
<whack>
>
> Chris F suggested,
>    He defiantly didn't see the benefit to switching to XMI, since XML 
> is harder
>    for him to understand than MI output.

That's uncharitable, try:
    Didn't see a big benefit in using one structured data format over 
the other. All things being equal, finds pages of MI easier to read 
than the order of magnitude longer output that XML would be.

> I don't really know where to go from here. The XML change I think is a 
> no brainer.
<snip>
>
> Finally, the difference between a text based protocol and a libgdb 
> interface is irrelevant
> to me. I would personally prefer the text based protocol at this point 
> in time seeing that
> there is no libgdb. What stopped the production of that effort?

Did license issues prevent adoption? I know that would likely keep me 
from being able to use a libgdb. Yeah, yeah dry your eyes. ;-)

Go for the Gold,
-ChrisF

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Chris Friesen <gdb001@speakeasy.net>:
>     Didn't see a big benefit in using one structured data format over 
> the other. All things being equal, finds pages of MI easier to read 
> than the order of magnitude longer output that XML would be.

yeah, that's my main issue with xml, it's not very human
readable, and it doesn't seem particularly easy to machine
process either, but the canned libraries hide most of that.

this isn't a strong objection, interoperability takes precedence.
I think an argument for xml would be more convincing if there
were more than one debugger talking the same protocol.  if the
schema is sensible, it shouldn't be too hard to make the python
debugger and the perl debugger and so forth speak the same xml.
--

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Fri, Aug 20, 2004 at 12:09:25AM -0700, Chris Friesen wrote:
> 
> On Aug 19, 2004, at 4:49 PM, Bob Rossi wrote:
> <whack>
> >
> >Chris F suggested,
> >   He defiantly didn't see the benefit to switching to XMI, since XML 
> >is harder
> >   for him to understand than MI output.
> 
> That's uncharitable, try:
>    Didn't see a big benefit in using one structured data format over 
> the other. All things being equal, finds pages of MI easier to read 
> than the order of magnitude longer output that XML would be.

I'm sorry, I worded that bad, didn't I? I did not mean "understand" as
in comprehend, anyways, thanks for correcting me.

> >I don't really know where to go from here. The XML change I think is a 
> >no brainer.
> <snip>
> >
> >Finally, the difference between a text based protocol and a libgdb 
> >interface is irrelevant
> >to me. I would personally prefer the text based protocol at this point 
> >in time seeing that
> >there is no libgdb. What stopped the production of that effort?
> 
> Did license issues prevent adoption? I know that would likely keep me 
> from being able to use a libgdb. Yeah, yeah dry your eyes. ;-)

Good point.

Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Fri, Aug 20, 2004 at 03:34:19AM -0700, Felix Lee wrote:
> Chris Friesen <gdb001@speakeasy.net>:
> >     Didn't see a big benefit in using one structured data format over 
> > the other. All things being equal, finds pages of MI easier to read 
> > than the order of magnitude longer output that XML would be.
> 
> yeah, that's my main issue with xml, it's not very human
> readable, and it doesn't seem particularly easy to machine
> process either, but the canned libraries hide most of that.

I think the main point behind XML is that it is human readable. Also,
every XML developer knows how to read it. Meaning that, I believe it
would take less time to learn how to read it, than some open source
project's grammar. BTW, you don't even have to learn how to read it,
because you don't have to parse it :) The only thing you need to know,
is the spec.

> this isn't a strong objection, interoperability takes precedence.
> I think an argument for xml would be more convincing if there
> were more than one debugger talking the same protocol.  

I can see that people are interested in writing front ends that parse the
output of the MI. Why? Do the same people enjoy writing linked lists
over and over again? Do you see my point? Parsing the output of MI is
completely a waste of time. 

> if the
> schema is sensible, it shouldn't be too hard to make the python
> debugger and the perl debugger and so forth speak the same xml.
> --

This is a great point.

Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I think the main point behind XML is that it is human readable. Also,
> every XML developer knows how to read it. Meaning that, I believe it
> would take less time to learn how to read it, than some open source
> project's grammar. BTW, you don't even have to learn how to read it,
> because you don't have to parse it :) The only thing you need to know,
> is the spec.

xml always reminds me of a less-readable form of COBOL.  I have a
hard time spotting errors like 'wrong value' in xml, because it's
filled with a lot of visual noise that doesn't particularly help
humans or machines read it (similar to what Edward Tufte calls
'chartjunk').

> I can see that people are interested in writing front ends that parse the
> output of the MI. Why? Do the same people enjoy writing linked lists
> over and over again? Do you see my point? Parsing the output of MI is
> completely a waste of time. 

I don't know about anyone else.  it's not that I particularly
enjoy writing parsers, but xml triggers my 'big and bloaty'
reflex.  when efficiency isn't important, I tend to favor lisp
syntax, which to me is a lot more readable than xml.  and I feel
like 'include a lisp interpreter' is less code complexity and
less resource requirements than 'use a validating xml parser',
but I haven't done formal measurements of that.

(yaml might be a reasonable alternative for people who dislike
lisp and xml.)

basically, xml annoys me on an aesthetic level, and it seems to
me it's based on unsound philosophical assumptions, but since the
whole computer world seems intent on using it... *shrug* it
mostly makes me want to leave the computer industry, much like
the dominance of Windows.  but of course, this isn't relevant to
anyone else.

if someone with time and motivation wants to implement and
maintain an xml schema for debugger gui<->backend interaction,
that's probably a good thing.
--

Re: GDB/XMI (XML Machine Interface)

[Daniel Jacobowitz]

On Fri, Aug 20, 2004 at 08:54:43AM -0400, Bob Rossi wrote:
> On Fri, Aug 20, 2004 at 03:34:19AM -0700, Felix Lee wrote:
> > this isn't a strong objection, interoperability takes precedence.
> > I think an argument for xml would be more convincing if there
> > were more than one debugger talking the same protocol.  
> 
> I can see that people are interested in writing front ends that parse the
> output of the MI. Why? Do the same people enjoy writing linked lists
> over and over again? Do you see my point? Parsing the output of MI is
> completely a waste of time. 

Parsing MI over and over again from scratch may be a waste of time.  So
write once a library that parses MI.  Then you gain most of the benefit
of having XML parsing libraries available.

Heck, parse it into XML if you'd like.

-- 
Daniel Jacobowitz

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Fri, Aug 20, 2004 at 02:34:48PM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 20, 2004 at 08:54:43AM -0400, Bob Rossi wrote:
> > On Fri, Aug 20, 2004 at 03:34:19AM -0700, Felix Lee wrote:
> > > this isn't a strong objection, interoperability takes precedence.
> > > I think an argument for xml would be more convincing if there
> > > were more than one debugger talking the same protocol.  
> > 
> > I can see that people are interested in writing front ends that parse the
> > output of the MI. Why? Do the same people enjoy writing linked lists
> > over and over again? Do you see my point? Parsing the output of MI is
> > completely a waste of time. 
> 
> Parsing MI over and over again from scratch may be a waste of time.  So
> write once a library that parses MI.  Then you gain most of the benefit
> of having XML parsing libraries available.

Why would I write it once? That would be a waste of my time. 

> Heck, parse it into XML if you'd like.

I don't want the data to be in XML. I just want the data without writing
a parser. and a protocol that is backwards compatible. This seems like a
simple think to ask for.

If GDB expects to have one common MI library, than it should distribute
a library that is responsible for reading it's own output, and giving
the user some data structures that will be backwards compatible. Thus, a
library to link against.

Bob Rossi 

Re: GDB/XMI (XML Machine Interface)

[Daniel Jacobowitz]

On Fri, Aug 20, 2004 at 02:49:00PM -0400, Bob Rossi wrote:
> On Fri, Aug 20, 2004 at 02:34:48PM -0400, Daniel Jacobowitz wrote:
> > On Fri, Aug 20, 2004 at 08:54:43AM -0400, Bob Rossi wrote:
> > > On Fri, Aug 20, 2004 at 03:34:19AM -0700, Felix Lee wrote:
> > > > this isn't a strong objection, interoperability takes precedence.
> > > > I think an argument for xml would be more convincing if there
> > > > were more than one debugger talking the same protocol.  
> > > 
> > > I can see that people are interested in writing front ends that parse the
> > > output of the MI. Why? Do the same people enjoy writing linked lists
> > > over and over again? Do you see my point? Parsing the output of MI is
> > > completely a waste of time. 
> > 
> > Parsing MI over and over again from scratch may be a waste of time.  So
> > write once a library that parses MI.  Then you gain most of the benefit
> > of having XML parsing libraries available.
> 
> Why would I write it once? That would be a waste of my time. 

So that all front ends could use it.

> > Heck, parse it into XML if you'd like.
> 
> I don't want the data to be in XML. I just want the data without writing
> a parser. and a protocol that is backwards compatible. This seems like a
> simple think to ask for.
> 
> If GDB expects to have one common MI library, than it should distribute
> a library that is responsible for reading it's own output, and giving
> the user some data structures that will be backwards compatible. Thus, a
> library to link against.

So, it would be a waste of your time to write a parser that all future
front ends could use, but not a waste of GDB developers' time to carry
out major incompatible surgery on GDB's output format for people that
already parse MI?

-- 
Daniel Jacobowitz

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Daniel Jacobowitz <drow@false.org>:
> Parsing MI over and over again from scratch may be a waste of time.  So
> write once a library that parses MI.  Then you gain most of the benefit
> of having XML parsing libraries available.

xml has the advantage of being language neutral.  a library in C
or whatever takes more work to use in other languages.
--

Re: GDB/XMI (XML Machine Interface)

[Daniel Jacobowitz]

On Fri, Aug 20, 2004 at 12:06:22PM -0700, Felix Lee wrote:
> Daniel Jacobowitz <drow@false.org>:
> > Parsing MI over and over again from scratch may be a waste of time.  So
> > write once a library that parses MI.  Then you gain most of the benefit
> > of having XML parsing libraries available.
> 
> xml has the advantage of being language neutral.  a library in C
> or whatever takes more work to use in other languages.

Oh, come on.  That's why I suggested writing a library that parses the
MI and outputs XML.  You run that as a wrapper around GDB; that's real
easy.

-- 
Daniel Jacobowitz

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Daniel Jacobowitz <drow@false.org>:
> Oh, come on.  That's why I suggested writing a library that parses the
> MI and outputs XML.  You run that as a wrapper around GDB; that's real
> easy.

oh, right.  ok, that works for me.
--

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

> > > Heck, parse it into XML if you'd like.
> > 
> > I don't want the data to be in XML. I just want the data without writing
> > a parser. and a protocol that is backwards compatible. This seems like a
> > simple think to ask for.
> > 
> > If GDB expects to have one common MI library, than it should distribute
> > a library that is responsible for reading it's own output, and giving
> > the user some data structures that will be backwards compatible. Thus, a
> > library to link against.
> 
> So, it would be a waste of your time to write a parser that all future
> front ends could use, but not a waste of GDB developers' time to carry
> out major incompatible surgery on GDB's output format for people that
> already parse MI?

What? I am saying that if GDB wants to stick with this self invented
grammer and decides that it is obviously silly to have all of the
consumers reinventing the wheel, it should write a library that parses
the MI output and give it to the user in some sort of ADT. Making the
protocol transparent. If this existed, I would be satisfied.

I wouldn't expect anyone but myself and people that believed in the idea
to carry out the surgery. I am not asking for a present.

I feel that an XML approach will save developers time over the long run
and that inventing a grammer to parse on output was a mistake in the
first place. 

Is the *main* argument to stick with MI because there is already a
customer base?

Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Daniel Jacobowitz]

On Fri, Aug 20, 2004 at 03:24:58PM -0400, Bob Rossi wrote:
> > > > Heck, parse it into XML if you'd like.
> > > 
> > > I don't want the data to be in XML. I just want the data without writing
> > > a parser. and a protocol that is backwards compatible. This seems like a
> > > simple think to ask for.
> > > 
> > > If GDB expects to have one common MI library, than it should distribute
> > > a library that is responsible for reading it's own output, and giving
> > > the user some data structures that will be backwards compatible. Thus, a
> > > library to link against.
> > 
> > So, it would be a waste of your time to write a parser that all future
> > front ends could use, but not a waste of GDB developers' time to carry
> > out major incompatible surgery on GDB's output format for people that
> > already parse MI?
> 
> What? I am saying that if GDB wants to stick with this self invented
> grammer and decides that it is obviously silly to have all of the
> consumers reinventing the wheel, it should write a library that parses
> the MI output and give it to the user in some sort of ADT. Making the
> protocol transparent. If this existed, I would be satisfied.
> 
> I wouldn't expect anyone but myself and people that believed in the idea
> to carry out the surgery. I am not asking for a present.

That's what I was suggesting you do - write that library.

> I feel that an XML approach will save developers time over the long run
> and that inventing a grammer to parse on output was a mistake in the
> first place. 
> 
> Is the *main* argument to stick with MI because there is already a
> customer base?

There's no "main" argument, but there seem to be lots of existing
arguments.  Myself, I don't have much reason to care, but I agree with
Chris that typiing XML by hand is a real pain, but MI is manageable
(and I do it periodically).

I don't think that using XML would change anything.  Several people
have already presented my opinion better than I could.

-- 
Daniel Jacobowitz

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Fri, Aug 20, 2004 at 03:42:24PM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 20, 2004 at 03:24:58PM -0400, Bob Rossi wrote:
> > > > > Heck, parse it into XML if you'd like.
> > > > 
> > > > I don't want the data to be in XML. I just want the data without writing
> > > > a parser. and a protocol that is backwards compatible. This seems like a
> > > > simple think to ask for.
> > > > 
> > > > If GDB expects to have one common MI library, than it should distribute
> > > > a library that is responsible for reading it's own output, and giving
> > > > the user some data structures that will be backwards compatible. Thus, a
> > > > library to link against.
> > > 
> > > So, it would be a waste of your time to write a parser that all future
> > > front ends could use, but not a waste of GDB developers' time to carry
> > > out major incompatible surgery on GDB's output format for people that
> > > already parse MI?
> > 
> > What? I am saying that if GDB wants to stick with this self invented
> > grammer and decides that it is obviously silly to have all of the
> > consumers reinventing the wheel, it should write a library that parses
> > the MI output and give it to the user in some sort of ADT. Making the
> > protocol transparent. If this existed, I would be satisfied.
> > 
> > I wouldn't expect anyone but myself and people that believed in the idea
> > to carry out the surgery. I am not asking for a present.
> 
> That's what I was suggesting you do - write that library.

I am not interested in writing this library. I am interested in the XML
approach. Do you know why yet? It's because I won't have to write a
library. No one will. Ever.

> > I feel that an XML approach will save developers time over the long run
> > and that inventing a grammer to parse on output was a mistake in the
> > first place. 
> > 
> > Is the *main* argument to stick with MI because there is already a
> > customer base?
> 
> There's no "main" argument, but there seem to be lots of existing
> arguments.  Myself, I don't have much reason to care, but I agree with
> Chris that typiing XML by hand is a real pain, but MI is manageable
> (and I do it periodically).
> 
> I don't think that using XML would change anything.  Several people
> have already presented my opinion better than I could.

You are missing the point. It would change the amount of work a front
end writer had to do to implement to GDB.  XML is clearly a better
approach to communicating data between 2 entities. It is a proven
technique that has parsers written in many languages.

Changing the MI output to XML would greatly reduce the amount of time
and code written to interface with GDB. Period. I strongly believe there
is no argument against this point.

Other reasons for not wanting to switch to XML seem relavant, such as,
typeing XML commands to talk to GDB. However, I have two arguments to
that. 
   If you were to send XML commands to GDB, most of the time they would
   be short.
   <next/>

   Second, the commands sent to GDB don't have to be XML, although I
   think that they should be.

BTW, how does one go about getting a yes/no answer to such an RFC? Do I
need the approval of the majority of GDB contributors? maintainers?

Also, why haven't some of the maintainers of MI responded at all on this
subject? Andrew or Elena? Fernando are you the main contact as far as
decisions on the MI code goes?

Thanks,
Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I am not interested in writing this library. I am interested in the XML
> approach. Do you know why yet? It's because I won't have to write a
> library. No one will. Ever.

parsing mi is trivial.  writing a wrapper to do bidirectional
translation to xml is trivial.  designing the schema is the hard
part.  all this can be done without changes to gdb itself.  if
it's workable and maintainable, then it will be easier to
convince people to absorb it into the gdb source and remove the
indirection so that gdb speaks xml 'natively'.
--

Re: GDB/XMI (XML Machine Interface)

[Eli Zaretskii]

> Date: Fri, 20 Aug 2004 15:59:28 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> Changing the MI output to XML would greatly reduce the amount of time
> and code written to interface with GDB. Period. I strongly believe there
> is no argument against this point.

Strangely enough, none of the maintainers of the GDB front ends were
enthusiastic about your proposal.  Perhaps that's because they already
have their MI parser written, so the issue of reducing the effort of
writing one does not bother them.

> BTW, how does one go about getting a yes/no answer to such an RFC? Do I
> need the approval of the majority of GDB contributors? maintainers?

If you are looking for approval before you write the code, you've just
heard the relevant opinions.  I believe this is all you can hope for.
Whether that is enough for you to sit down and start writing is
something you should decide on your own.

The way to get something into GDB is to write code and then submit it
for approval.  Then there are designated individuals (mentioned in
MAINTAINERS) who should review the code and either approve it or point
out the parts that should be rewritten or corrected.

> Also, why haven't some of the maintainers of MI responded at all on this
> subject? Andrew or Elena? Fernando are you the main contact as far as
> decisions on the MI code goes?

I'm neither Andrew nor Elena nor Fernando, but I will try to summarize
the impression I got from this discussion so far: your proposal
mentioned several problems with MI, but most of those problems can
(and IMHO should) be solved without ditching MI, and the effort to
solve those problems with XMI is not going to be smaller.  One notable
example of such problems is back compatibility, but there were others.

So, by and large, your proposal seems to be not a silver bullet, but
rather an additional burden on the GDB maintenance, i.e. yet another
interface language and interpreter that can easily run the same risk
of bit rotting as the other interfaces.

I agree that it would be a Good Thing if GDB would come with a
read-to-use MI parser library.  If you care about easing the pains of
a GDB front-end programmer, then the project of writing such a parsing
library should sound important to you.  But since you said quite
explicitly that you are not interested in such a project, I suspect
that your interest is in playing with XML rather than easing the lives
of front-end programmers out there.  There's nothing wrong with your
interest in XML, of course, but you must understand that the interests
of GDB maintainers are elsewhere, and rightly so.

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Sat, Aug 21, 2004 at 01:20:33PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 20 Aug 2004 15:59:28 -0400
> > From: Bob Rossi <bob@brasko.net>
> > 
> > Changing the MI output to XML would greatly reduce the amount of time
> > and code written to interface with GDB. Period. I strongly believe there
> > is no argument against this point.
> 
> Strangely enough, none of the maintainers of the GDB front ends were
> enthusiastic about your proposal.  Perhaps that's because they already
> have their MI parser written, so the issue of reducing the effort of
> writing one does not bother them.

Right, this is understandably so. I would also not be interested if I
had already written my mi1 and mi2 parser. However, that doesn't mean
it's not the correct decision. Instead of writing a new parser, they
will get one for free, that they will never have to maintain. Doesn't
that sound nice?

> > BTW, how does one go about getting a yes/no answer to such an RFC? Do I
> > need the approval of the majority of GDB contributors? maintainers?
> 
> If you are looking for approval before you write the code, you've just
> heard the relevant opinions.  I believe this is all you can hope for.
> Whether that is enough for you to sit down and start writing is
> something you should decide on your own.
> 
> The way to get something into GDB is to write code and then submit it
> for approval.  Then there are designated individuals (mentioned in
> MAINTAINERS) who should review the code and either approve it or point
> out the parts that should be rewritten or corrected.

These designated individuals either are busy or refuse to even discuss
the topic at hand. This is awfully unfriendly.

> > Also, why haven't some of the maintainers of MI responded at all on this
> > subject? Andrew or Elena? Fernando are you the main contact as far as
> > decisions on the MI code goes?
> 
> I'm neither Andrew nor Elena nor Fernando, but I will try to summarize
> the impression I got from this discussion so far: your proposal
> mentioned several problems with MI, but most of those problems can
> (and IMHO should) be solved without ditching MI, and the effort to
> solve those problems with XMI is not going to be smaller.  One notable
> example of such problems is back compatibility, but there were others.

I believe that making GDB output XML would be trivial.

> I agree that it would be a Good Thing if GDB would come with a
> read-to-use MI parser library.  If you care about easing the pains of
> a GDB front-end programmer, then the project of writing such a parsing
> library should sound important to you.  But since you said quite
> explicitly that you are not interested in such a project, 

I am going to have to write an MI parser, if GDB refuses to simplfy it's
output. I have already been working on a project TGDB, and anyone that
wants to use it to base there front ends on GDB is welcome.

> I suspect
> that your interest is in playing with XML rather than easing the lives
> of front-end programmers out there.  There's nothing wrong with your
> interest in XML, of course, but you must understand that the interests
> of GDB maintainers are elsewhere, and rightly so.

I care nothing about XML. As I say it over and over again. If XML is
outputted by GDB, it could be binary for all I care, NO parser has to be
written. The job has already been done.

   I would not have to write a parser.
   I would not have to write a library.
   No one would.
   Ever.

This is my point. I think that might have been my very first epilogue :)

BTW, if none of the front end writers or maintainers like this idea, I
will silently drop the issue. Personally, I thought  many of the front
end writers would appreciate such a transparent protocol.

Thanks,
Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Fri, Aug 20, 2004 at 12:19:58PM -0700, Felix Lee wrote:
> Daniel Jacobowitz <drow@false.org>:
> > Oh, come on.  That's why I suggested writing a library that parses the
> > MI and outputs XML.  You run that as a wrapper around GDB; that's real
> > easy.
> 
> oh, right.  ok, that works for me.
> --

I think there are other benefits of working with XML. Basically, people
that want to use GDB for a small part of there project, could quickly
write some code to get GDB to give a backtrace, or perform some other
activity. I believe  that making GDB output XML would almost make it
scriptable. Someone writing in perl or java could quickly conjure up
some commands and parse the output of GDB in a matter of minutes.

This will never happen with MI.

Thanks,
Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Eli Zaretskii]

> Date: Sat, 21 Aug 2004 08:34:40 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> These designated individuals either are busy or refuse to even discuss
> the topic at hand.

I was talking about code submitted for inclusion, not about ideas.

> > I'm neither Andrew nor Elena nor Fernando, but I will try to summarize
> > the impression I got from this discussion so far: your proposal
> > mentioned several problems with MI, but most of those problems can
> > (and IMHO should) be solved without ditching MI, and the effort to
> > solve those problems with XMI is not going to be smaller.  One notable
> > example of such problems is back compatibility, but there were others.
> 
> I believe that making GDB output XML would be trivial.

I don't think so, but that was not what I meant to say in the portion
you cited.

I meant to say that to overcome most of the problems you mentioned
(saying that they originate from MI usage), it will not be enough just
to teach GDB speak XML.  Overcoming those problems will need
additional effort, regardless of whether GDB speaks XML or not.
Others explained in detail why is that so, but if you want to discuss
it again, let's take the back compatibility issue and analyze it.

> > I agree that it would be a Good Thing if GDB would come with a
> > read-to-use MI parser library.  If you care about easing the pains of
> > a GDB front-end programmer, then the project of writing such a parsing
> > library should sound important to you.  But since you said quite
> > explicitly that you are not interested in such a project, 
> 
> I am going to have to write an MI parser, if GDB refuses to simplfy it's
> output.

Then how about doing what I believe was proposed in this thread: write
an MI parsing library that every front-end programmer could use
henceforth?  I thought you said that you were not interested in doing
that, but I cannot understand why, given the fact that you will be the
very first user of such a library.

> I care nothing about XML. As I say it over and over again. If XML is
> outputted by GDB, it could be binary for all I care, NO parser has to be
> written. The job has already been done.
> 
>    I would not have to write a parser.
>    I would not have to write a library.
>    No one would.
>    Ever.

That might be true, but then we will need to solve the problem of
changes in the XMI in some way, be it via DTD or otherwise.  Producing
a DTD and maintaining it in sync with the modifications in XMI is a
maintenance burden we currently don't have.

Also, the effort to teach GDB speak XML is a non-trivial effort, and
maintaining that together with MI and annotations (as we cannot simply
drop existing interfaces overnight) is in itself a burden.

So, more generally, one can say that switching to XML does not
miraculously remove the need to invest some effort when we change the
output syntax.  Therefore, we need to weight the advantages and
disadvantages of your proposal, which is what this discussion was all
about, I believe.  So it's not that people here are somehow prejudiced
against XML, they simply think that the benefits from going XML are
not significant enough, while most of the problems that exist with MI
will not be solved by switching to XML.

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I believe  that making GDB output XML would almost make it
> scriptable. Someone writing in perl or java could quickly conjure up
> some commands and parse the output of GDB in a matter of minutes.

what about MI makes you feel like gdb isn't scriptable now?  MI
seems pretty easy to pull apart with regexps.

anyway, a wrapper that translates gdb's interface to xml would
also let anyone do what you want.
--

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I believe that making GDB output XML would be trivial.

ok, so submit a patch to implement --interpreter=xml.
--

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Sat, Aug 21, 2004 at 12:28:11PM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > I believe that making GDB output XML would be trivial.
> 
> ok, so submit a patch to implement --interpreter=xml.
> --

Well of course I was going to implement a patch, or at least try. The
point is to get some sort of consensus as to if the patch would be
approved. I would think it not very nice of the GDB team to set me loose
on this patch, and then outright reject it. Where is the open source
camaraderie?

Thanks,
Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Sat, Aug 21, 2004 at 12:21:44PM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > I believe  that making GDB output XML would almost make it
> > scriptable. Someone writing in perl or java could quickly conjure up
> > some commands and parse the output of GDB in a matter of minutes.
> 
> what about MI makes you feel like gdb isn't scriptable now?  MI
> seems pretty easy to pull apart with regexps.

That is ridiculous. Let me make something clear. In order to integrate
GDB with, say perl, you would either 

   1. Have to write a parser. (regex, recursive decent)
      BTW, I guarantee the parser will have to be updated with every
      release of GDB.
   2. Do nothing but use the information given to you.
      BTW, you will never ever have to worry about what GDB outputs,
      because it is irrelevant. You get the info you want, and you use
      it.

Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Bob Rossi <bob@brasko.net>:
>    1. Have to write a parser. (regex, recursive decent)
>       BTW, I guarantee the parser will have to be updated with every
>       release of GDB.

so far, I haven't found that xml is any less work than that, and
it usually feels like a lot more work, but I haven't used xml for
anything substantial yet, so it may just be unfamiliarity.
--

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I would think it not very nice of the GDB team to set me loose
> on this patch, and then outright reject it. Where is the open source
> camaraderie?

I don't think any open source project can promise to accept a
patch before seeing it.  if you don't want to put effort into
that risk, then how about putting effort into a separate xmlgdb
wrapper.  if enough people use it, then it's easy to argue for
inclusion in the source tree, and perhaps making it an interp
module rather than a wrapper.

don't let the discussion discourage you if you're sure xml is the
right approach.  you can trump many arguments with working code
and a user base.
--

GDB/MI snapshots between major release's

[Bob Rossi]

Hi,

To make things simple, I am separating some of my questions out into
several threads as Eli suggested. There are only a few, and I hope they
are not to annoying.

How should front end developers deal with snapshots of GDB, that are
taken between major versions of GDB. Several distributions
do this and I don't think most front end's would be capable of dealing
with a GDB in this state. In this state, GDB says it is MI3 but outputs commands
in the MI4 style (because version hasn't been bumped yet) or vice versa.
Does this even happen?

Here is my take, since Eli stated that MI is backwards compatible, I
think the version number should be bumped right before the release. This
way, any snapshot of GDB will get the last major version of the MI
protocol that was publically released and supported. Does this sound
correct?

Thanks,
Bob Rossi

probing GDB for MI versions

[Bob Rossi]

Hi,

I want to figure out the best way to probe GDB for the versions of MI
that it supports. If you know of a better way than the one I'm
suggesting below, please let me know.

I want to add a --mi-protocols flag to GDB, and when it is invoked with
this flag, the only thing that it will output is the versions of MI that
it supports each, on it's own line. For example,

gdb --mi-protocols
MI1
MI2
MI3

What does everyone think? With this command, it would be safe to say
that I could always probe GDB to figure out what version of MI the front
end should use with the current GDB.

The only problem with this approach is that it obviously won't work for
GDB's before this command was implemented. However, in that case, the
user can either assume MI1 (if that's the only publically released
version) or they can try MI2.

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> How should front end developers deal with snapshots of GDB, that are
> taken between major versions of GDB. Several distributions

I think you're overthinking this.  if some version of gdb doesn't
fulfill the compatibility guarantee, then it's a bug in gdb, and
it shouldn't be hard to have the user install a gdb version
without the bug.  at worst, you can supply your own version of
gdb.  few things depend on specific gdb version.  it's not a big
deal to have multiple gdb versions installed.  source code
availability means you don't have to wait for the gdb cabal to
fix it, and the cabal is generally eager to take reasonable
bugfixes, which solves the long-term problem.
--

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Sun, Oct 03, 2004 at 11:00:30AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > How should front end developers deal with snapshots of GDB, that are
> > taken between major versions of GDB. Several distributions
> 
> I think you're overthinking this.  if some version of gdb doesn't
> fulfill the compatibility guarantee, then it's a bug in gdb, and
> it shouldn't be hard to have the user install a gdb version
> without the bug.  at worst, you can supply your own version of
> gdb.  few things depend on specific gdb version.  it's not a big
> deal to have multiple gdb versions installed.  source code
> availability means you don't have to wait for the gdb cabal to
> fix it, and the cabal is generally eager to take reasonable
> bugfixes, which solves the long-term problem.

I would say that I am not overthinking it, I am simply thinking about
it. I want to make sure that CVS snapshots will support a valid MI
interface. Major distro's use these snapshots, and I would like to have
compatibility with them.

Bob Rossi

Re: GDB/MI snapshots between major release's

[Daniel Jacobowitz]

On Sun, Oct 03, 2004 at 02:36:18PM -0400, Bob Rossi wrote:
> On Sun, Oct 03, 2004 at 11:00:30AM -0700, Felix Lee wrote:
> > Bob Rossi <bob@brasko.net>:
> > > How should front end developers deal with snapshots of GDB, that are
> > > taken between major versions of GDB. Several distributions
> > 
> > I think you're overthinking this.  if some version of gdb doesn't
> > fulfill the compatibility guarantee, then it's a bug in gdb, and
> > it shouldn't be hard to have the user install a gdb version
> > without the bug.  at worst, you can supply your own version of
> > gdb.  few things depend on specific gdb version.  it's not a big
> > deal to have multiple gdb versions installed.  source code
> > availability means you don't have to wait for the gdb cabal to
> > fix it, and the cabal is generally eager to take reasonable
> > bugfixes, which solves the long-term problem.
> 
> I would say that I am not overthinking it, I am simply thinking about
> it. I want to make sure that CVS snapshots will support a valid MI
> interface. Major distro's use these snapshots, and I would like to have
> compatibility with them.

So, use the last frozen MI version supported by that snapshot?

-- 
Daniel Jacobowitz

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Sun, Oct 03, 2004 at 02:40:36PM -0400, Daniel Jacobowitz wrote:
> On Sun, Oct 03, 2004 at 02:36:18PM -0400, Bob Rossi wrote:
> > On Sun, Oct 03, 2004 at 11:00:30AM -0700, Felix Lee wrote:
> > > Bob Rossi <bob@brasko.net>:
> > > > How should front end developers deal with snapshots of GDB, that are
> > > > taken between major versions of GDB. Several distributions
> > > 
> > > I think you're overthinking this.  if some version of gdb doesn't
> > > fulfill the compatibility guarantee, then it's a bug in gdb, and
> > > it shouldn't be hard to have the user install a gdb version
> > > without the bug.  at worst, you can supply your own version of
> > > gdb.  few things depend on specific gdb version.  it's not a big
> > > deal to have multiple gdb versions installed.  source code
> > > availability means you don't have to wait for the gdb cabal to
> > > fix it, and the cabal is generally eager to take reasonable
> > > bugfixes, which solves the long-term problem.
> > 
> > I would say that I am not overthinking it, I am simply thinking about
> > it. I want to make sure that CVS snapshots will support a valid MI
> > interface. Major distro's use these snapshots, and I would like to have
> > compatibility with them.
> 
> So, use the last frozen MI version supported by that snapshot?

Yes, that's what I was thinking also. Is that what is expected? Finally,
this idea along with this new command line argument,
http://sources.redhat.com/ml/gdb/2004-10/msg00027.html

I would be able to figure out the last stable version of MI is and use it,
even when it is a CVS snapshot. 

Does this sound correct? I figure the command line argument
--mi-protocols will only output the versions of MI that were released as
stable ( for a release ).

This would solve several important problem for me.

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I would say that I am not overthinking it, I am simply thinking about
> it. I want to make sure that CVS snapshots will support a valid MI
> interface. Major distro's use these snapshots, and I would like to have
> compatibility with them.

the gdb testsuite has tests that exercise the MI versions.
'successfully passing the MI tests' is a form of compatibility
guarantee.  if the existing tests aren't a strong enough
guarantee, then new tests can be added.  the bigger problem is
insufficient manpower to fix known failures.
--

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Sun, Oct 03, 2004 at 12:35:47PM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > I would say that I am not overthinking it, I am simply thinking about
> > it. I want to make sure that CVS snapshots will support a valid MI
> > interface. Major distro's use these snapshots, and I would like to have
> > compatibility with them.
> 
> the gdb testsuite has tests that exercise the MI versions.
> 'successfully passing the MI tests' is a form of compatibility
> guarantee.  if the existing tests aren't a strong enough
> guarantee, then new tests can be added.  

This is great news!

> the bigger problem is
> insufficient manpower to fix known failures.

Is there a list of these known failures or problems?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> Is there a list of these known failures or problems?

here's one list, for redhat-8.0
    http://www.shout.net/~mec/sunday/current/
for mi tests, search for the string 'gdb.mi'
--

Re: GDB/MI snapshots between major release's

[Eli Zaretskii]

> Date: Sun, 3 Oct 2004 12:39:18 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> Here is my take, since Eli stated that MI is backwards compatible, I
> think the version number should be bumped right before the release.

The MI number should be bumped when an incompatibility is introduced
on purpose, i.e. at the very moment when we decide to start a new MI
version.

Re: probing GDB for MI versions

[Eli Zaretskii]

> Date: Sun, 3 Oct 2004 13:01:04 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> gdb --mi-protocols
> MI1
> MI2
> MI3
> 
> What does everyone think? With this command, it would be safe to say
> that I could always probe GDB to figure out what version of MI the front
> end should use with the current GDB.

If at all, I'd prefer this to be an MI command, not a command-line
switch.

It won't solve this problem, of course:

> The only problem with this approach is that it obviously won't work for
> GDB's before this command was implemented. However, in that case, the
> user can either assume MI1 (if that's the only publically released
> version) or they can try MI2.

To solve that, a front end that is willing to support old versions of
GDB will need to have a database of old GDB versions and the MI
versions they supported.  A front end could have this database for all
versions of GDB, which is why the benefit from adding the suggested
command is relatively small, IMHO.

Re: probing GDB for MI versions

[Bob Rossi]

On Mon, Oct 04, 2004 at 07:01:28AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 3 Oct 2004 13:01:04 -0400
> > From: Bob Rossi <bob@brasko.net>
> > 
> > gdb --mi-protocols
> > MI1
> > MI2
> > MI3
> > 
> > What does everyone think? With this command, it would be safe to say
> > that I could always probe GDB to figure out what version of MI the front
> > end should use with the current GDB.
> 
> If at all, I'd prefer this to be an MI command, not a command-line
> switch.

Yes, I understand, that was my first idea. However, you can see that
it is a "catch 22". If you do not know what version of MI to start GDB
with, than you can not understand how to parse the output of the MI
commands. So, you can not call an MI function to figure out what version
to start GDB with.

I think it has to be a command line switch, although I'm open to
suggestions.

The more I think about it, we could change the command to be something
like --list-interfaces and it could look something like,

gdb --list-interfaces
annotate1
annotate2
annotate3
mi1
mi2
mi3

> It won't solve this problem, of course:
> 
> > The only problem with this approach is that it obviously won't work for
> > GDB's before this command was implemented. However, in that case, the
> > user can either assume MI1 (if that's the only publically released
> > version) or they can try MI2.
> 
> To solve that, a front end that is willing to support old versions of
> GDB will need to have a database of old GDB versions and the MI
> versions they supported.  

I don't see what the GDB versions have to do with, am I missing
something? I am only interested in the MI versions.

Thanks, 
Bob Rossi

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 06:57:35AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 3 Oct 2004 12:39:18 -0400
> > From: Bob Rossi <bob@brasko.net>
> > 
> > Here is my take, since Eli stated that MI is backwards compatible, I
> > think the version number should be bumped right before the release.
> 
> The MI number should be bumped when an incompatibility is introduced
> on purpose, i.e. at the very moment when we decide to start a new MI
> version.

OK, at first I don't like this idea for several reasons. It seems to me
that with this approach you could end up releasing GDB 6.0 with MI
version 1 and GDB 6.1 with MI version 5. Meaning that there could be
several versions of MI revisions between one major release.
It seems that you would have to run the testsuite on every incompatible
change that the MI protocol goes through, including several for only one
release. Also, a front end would have to understand all of these
revisions in hopes of working with the most recent GDB (CVS snapshots).

I have a suggestion, although I don't know how much it helps. I propose
that GDB changes the MI version once for every major release. It
documents the changes so that front end developers can update there
protocols appropriately from the last release. Finally, if the user
starts GDB like --interpreter=mi, it would actually give the current
development version of MI which is unsupported officially. Then the
front ends would have to query GDB for the officially supported released
protocols, and start GDB with the newest one they support.

Could this work well with the GDB team?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> OK, at first I don't like this idea for several reasons. It seems to me
> that with this approach you could end up releasing GDB 6.0 with MI
> version 1 and GDB 6.1 with MI version 5. Meaning that there could be
> several versions of MI revisions between one major release.
> It seems that you would have to run the testsuite on every incompatible
> change that the MI protocol goes through, including several for only one
> release. Also, a front end would have to understand all of these
> revisions in hopes of working with the most recent GDB (CVS snapshots).

I really don't understand what's the problem you're trying to
solve.  MI doesn't change often.  and even if it did, each
version of MI has separate tests in the testsuite.  a front-end
doesn't have to understand any MI changes if it doesn't want to,
if it understands MI5, it should invoke gdb with
--interpreter=mi5.

if the gdb doesn't understand mi5, then you can try fallback to
--interpreter=mi1.  I don't see much benefit to a front-end
knowing more than two versions of MI, and most of the time
knowing just one should be adequate.

if your front-end tries mi5 and fails because gdb has made an
incompatible change to mi5, then that's a bug in gdb, and if that
bug gets exposed in a user version of gdb, the answer is 'your
gdb has a bug, install a non-buggy one'.

what's your failure scenario?
--

Re: GDB/MI snapshots between major release's

[Mark Kettenis]

   Date: Mon, 4 Oct 2004 09:19:06 -0400
   From: Bob Rossi <bob@brasko.net>

   On Mon, Oct 04, 2004 at 06:57:35AM +0200, Eli Zaretskii wrote:
   > > Date: Sun, 3 Oct 2004 12:39:18 -0400
   > > From: Bob Rossi <bob@brasko.net>
   > > 
   > > Here is my take, since Eli stated that MI is backwards compatible, I
   > > think the version number should be bumped right before the release.
   > 
   > The MI number should be bumped when an incompatibility is introduced
   > on purpose, i.e. at the very moment when we decide to start a new MI
   > version.

   OK, at first I don't like this idea for several reasons. It seems to me
   that with this approach you could end up releasing GDB 6.0 with MI
   version 1 and GDB 6.1 with MI version 5. Meaning that there could be
   several versions of MI revisions between one major release.

Of course not.  We'd bump the MI version on the first incompatible
change after a release, but we wouldn't bump it again until after the
next release.  It's highly unlikely that we'd have to bump the MI
version for a patch release, except when there's a need to fix a
critical bug in the MI interface.  Yes, GDB 6.1 could be released with
MI version 2, 6.2, 6.3 with MI version 3, GDB 6.4 with MI version 4
and GDB 7.0 with MI version 5.  But since we aim for stability of the
MI interface, even that would be unlikely.

   It seems that you would have to run the testsuite on every incompatible
   change that the MI protocol goes through, including several for only one
   release. Also, a front end would have to understand all of these
   revisions in hopes of working with the most recent GDB (CVS snapshots).

In the end there will be no hope for a frontend to be compatible with
each and every CVS snapshot that's made.  If we go through the
development process we might add several features between two
releases.  All we can guarantee is that once we make an official GDB
release with a certain version of MI, that version of MI will never
change again, and will be supported in the next X GDB releases.

Seems like your problem is that various Linux distribution come with
their own hacked versions of GDB that do not correspond to an official
release.  Those distributions are not doing proper release management.
You should blame them, not the GDB developers.  Or you should tell
your users to use an OS with proper release management like *BSD ;-).

   I have a suggestion, although I don't know how much it helps. I propose
   that GDB changes the MI version once for every major release. It
   documents the changes so that front end developers can update there
   protocols appropriately from the last release. Finally, if the user
   starts GDB like --interpreter=mi, it would actually give the current
   development version of MI which is unsupported officially. Then the
   front ends would have to query GDB for the officially supported released
   protocols, and start GDB with the newest one they support.

   Could this work well with the GDB team?

No.

Mark

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 07:59:21AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > OK, at first I don't like this idea for several reasons. It seems to me
> > that with this approach you could end up releasing GDB 6.0 with MI
> > version 1 and GDB 6.1 with MI version 5. Meaning that there could be
> > several versions of MI revisions between one major release.
> > It seems that you would have to run the testsuite on every incompatible
> > change that the MI protocol goes through, including several for only one
> > release. Also, a front end would have to understand all of these
> > revisions in hopes of working with the most recent GDB (CVS snapshots).
> 
> I really don't understand what's the problem you're trying to
> solve.  MI doesn't change often.  

I'm not interested in how often it changes at all. I'm interested in
the fact that it does change.

> a front-end
> doesn't have to understand any MI changes if it doesn't want to,
> if it understands MI5, it should invoke gdb with
> --interpreter=mi5.

You are correct, a front end doesn't have to do anything if it doesn't
want to. 

However, I want my front end to understand every MI protocol and I think
that this is OK with the GDB people. Is it a goal of GDB to make sure
that front ends can not understand every protocol? I highly doubt it.

> if the gdb doesn't understand mi5, then you can try fallback to
> --interpreter=mi1.  I don't see much benefit to a front-end
> knowing more than two versions of MI, and most of the time
> knowing just one should be adequate.

Of course there is a benefit. A front end should know every version of
the MI protocol. Since it will know all of the protocols, it could work
with a given GDB using the latest/greatest protocol that that GDB
supported.

> if your front-end tries mi5 and fails because gdb has made an
> incompatible change to mi5, then that's a bug in gdb, and if that
> bug gets exposed in a user version of gdb, the answer is 'your
> gdb has a bug, install a non-buggy one'.
> 
> what's your failure scenario?

I don't know what you are talking about here. Can you see that I'm
interested in having a new front end start any GDB with it's newest MI
protocol?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 05:33:54PM +0200, Mark Kettenis wrote:
>    Date: Mon, 4 Oct 2004 09:19:06 -0400
>    From: Bob Rossi <bob@brasko.net>
> 
>    On Mon, Oct 04, 2004 at 06:57:35AM +0200, Eli Zaretskii wrote:
>    > > Date: Sun, 3 Oct 2004 12:39:18 -0400
>    > > From: Bob Rossi <bob@brasko.net>
>    > > 
>    > > Here is my take, since Eli stated that MI is backwards compatible, I
>    > > think the version number should be bumped right before the release.
>    > 
>    > The MI number should be bumped when an incompatibility is introduced
>    > on purpose, i.e. at the very moment when we decide to start a new MI
>    > version.
> 
>    OK, at first I don't like this idea for several reasons. It seems to me
>    that with this approach you could end up releasing GDB 6.0 with MI
>    version 1 and GDB 6.1 with MI version 5. Meaning that there could be
>    several versions of MI revisions between one major release.
> 
> Of course not.  We'd bump the MI version on the first incompatible
> change after a release, but we wouldn't bump it again until after the
> next release.  It's highly unlikely that we'd have to bump the MI
> version for a patch release, except when there's a need to fix a
> critical bug in the MI interface.  Yes, GDB 6.1 could be released with
> MI version 2, 6.2, 6.3 with MI version 3, GDB 6.4 with MI version 4
> and GDB 7.0 with MI version 5.  But since we aim for stability of the
> MI interface, even that would be unlikely.

OK, this is good news. So basically, even thought the MI version is
bumped it is still not official. Meaning, at that point, if I updated my
front end to be compatible with the new MI protocol version, there could
still be another incompatible change before the release. Meaning, I
would have to wait for the release to get the use out of that new
version. This is OK with me as long as,

   - I can have the --mi-protocols command line switch that tells me 
   what version of GDB/MI protocol is officially supported.

   - This command line switch only has MI protocols added to it when the 
   MI protocols become official ( for a release )

>    It seems that you would have to run the testsuite on every incompatible
>    change that the MI protocol goes through, including several for only one
>    release. Also, a front end would have to understand all of these
>    revisions in hopes of working with the most recent GDB (CVS snapshots).
> 
> In the end there will be no hope for a frontend to be compatible with
> each and every CVS snapshot that's made.  

Agreed, and I am learning that it would be wise to stay away from this
idea. It seems better that the front end understand somehow that the
current version is not official (CVS snapshot) and it should work with
the last official release.

> If we go through the
> development process we might add several features between two
> releases.  All we can guarantee is that once we make an official GDB
> release with a certain version of MI, that version of MI will never
> change again, and will be supported in the next X GDB releases.

This is perfect. Is this your view or the view of GDB/MI's maintainers
also?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I don't know what you are talking about here. Can you see that I'm
> interested in having a new front end start any GDB with it's newest MI
> protocol?

why isn't that possible now?  what situation makes it difficult
to do that?
--

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 09:04:55AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > I don't know what you are talking about here. Can you see that I'm
> > interested in having a new front end start any GDB with it's newest MI
> > protocol?
> 
> why isn't that possible now?  what situation makes it difficult
> to do that?

My original posting has the problem that I am confronting,

   How should front end developers deal with snapshots of GDB, that are
   taken between major versions of GDB. Several distributions
   do this and I don't think most front end's would be capable of dealing
   with a GDB in this state. In this state, GDB says it is MI3 but outputs commands
   in the MI4 style (because version hasn't been bumped yet) or vice versa.
   Does this even happen?

With the information I have now, here is the problem. A snapshot of GDB
will say that it is at MI4, although, it is really at some
developmental version. So, I need to get from GDB that MI4 is not an
official protocol, and that I should be using MI3 to communicate with
it. This seems to be the only problem.

This is why I am suggesting the new command line switch, which according
to the case above, would produce,

gdb --mi-protocols
mi1
mi2
mi3

However, Eli suggested making an MI command that does this, that is
still up for debate I guess.

Thanks,
Bob Rossi

gdbserver, sysroot, prelink

[Felix Lee]

if you use gdbserver to debug a program on a remote Fedora Core 2
machine, then you need to set solib-absolute-prefix to a copy of
the shared libraries from that specific machine.  you can't use
generic FC2 shared libraries, because 'prelink' in nightly cron
does arbitrary relocation of shared libraries on each machine.

this probably affects any system that uses prelink; I haven't
tried any other than FC2.

I don't think there's anything that needs fixing.  just pointing
out that configuring --with-sysroot is basically useless for any
system that uses prelink.
--

Re: gdbserver, sysroot, prelink

[Daniel Jacobowitz]

On Mon, Oct 04, 2004 at 10:37:36AM -0700, Felix Lee wrote:
> if you use gdbserver to debug a program on a remote Fedora Core 2
> machine, then you need to set solib-absolute-prefix to a copy of
> the shared libraries from that specific machine.  you can't use
> generic FC2 shared libraries, because 'prelink' in nightly cron
> does arbitrary relocation of shared libraries on each machine.
> 
> this probably affects any system that uses prelink; I haven't
> tried any other than FC2.
> 
> I don't think there's anything that needs fixing.  just pointing
> out that configuring --with-sysroot is basically useless for any
> system that uses prelink.

How does this make --with-sysroot useless?  That's exactly what sysroot
is supposed to do - point it where you keep the exact libraries of the
machine.  I usually point it to an NFS server.

Yes, prelink randomization does invalidate sysroots.

-- 
Daniel Jacobowitz

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> With the information I have now, here is the problem. A snapshot of GDB
> will say that it is at MI4, although, it is really at some
> developmental version.

does that ever happen?  if gdb says it supports MI4 but it
doesn't really, then it's lying, and that's a bug.  I think it's
unreasonable to expect a front-end to have workarounds for every
gdb bug.  the best answer is often 'get a gdb without the bug'.
it might be reasonable to have workarounds for bugs in gdb
versions that are widely deployed, and that can be handled on a
case-by-case basis.

I don't have any objection to an --mi-protocols switch, but it
seems to me that it isn't really needed by front-ends.  one
simple strategy is to just try each mi version you know until you
find one that works.
--

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 11:12:01AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > With the information I have now, here is the problem. A snapshot of GDB
> > will say that it is at MI4, although, it is really at some
> > developmental version.
> 
> does that ever happen?  if gdb says it supports MI4 but it
> doesn't really, then it's lying, and that's a bug.  I think it's
> unreasonable to expect a front-end to have workarounds for every
> gdb bug.  the best answer is often 'get a gdb without the bug'.
> it might be reasonable to have workarounds for bugs in gdb
> versions that are widely deployed, and that can be handled on a
> case-by-case basis.

Felix, I think either I am wrong here about how GDB bumps it's version
numbers, or you do not understand what I am talking about. I am often
blamed for not explaining things clearly, so here it goes again.

While GDB is between versions, it will bump it's MI protocol number by
one if there is an MI backwards compatible issue. Right? (this was
stated by Mark Kettenis )

OK, so, if you get snapshots of GDB during it's development, the newly
bumped version of the MI protocol is *not* a valid protocol. It is a
protocol under development that will become an official protocol only
after a release is made. Here is a simple example, 
T1 GDB 7.0 has MI10 (official)
T2 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X1 )
T3 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X2 )
T4 GDB 7.1 has MI11 (official)

The assertion is GDB is not necessarily talking an official MI protocol 
until the release.

If I get a snapshot of GDB when in development, between time T2 and T3,
then my front end will not work with GDB's MI11 protocol. It will only
work with MI10. So, I need to find out from GDB what version's it will
officially support, and then the issue of working with GDB snapshots
will go away for ever (hopefully). 


> I don't have any objection to an --mi-protocols switch, but it
> seems to me that it isn't really needed by front-ends.  one
> simple strategy is to just try each mi version you know until you
> find one that works.

GDB currently says that it supports MI11 between times T2 and T3,
however, this is not true. It is a developmental version, that does not
conform to any specific version of the MI protocol.

Do you see the problem I am describing?

Here is debian testing ( the first system I tried ).
$ gdb --version
GNU gdb 2002-04-01-cvs

We don't have to have all the package maintainers give a formal snapshot
of GDB, we just need to make front end's understand all of the official
protocols that a given GDB supports.

Thanks,
Bob Rossi

Re: gdbserver, sysroot, prelink

[Felix Lee]

Daniel Jacobowitz <drow@false.org>:
> How does this make --with-sysroot useless?  That's exactly what sysroot
> is supposed to do - point it where you keep the exact libraries of the
> machine.  I usually point it to an NFS server.

doesn't that assume you only have one such target machine in your
installation?  in most setups I can think of, the sysroot symlink
has to be created by hand by the end-user of gdb, since he's the
one who decides what remote machine he's using.  I can't think
of a reasonable way for a packager or an installer to create a
default sysroot, since there's no place to tell gdb to use a
default remote machine.  so the gdb user might as well set
solib-absolute-prefix in his gdbinit, since that doesn't require
installation privs.

this problem is specific to gdb.  gcc doesn't care about the
prelink mangling, so for gcc purposes it's fine to use a generic
sysroot for the target.

this problem creates mysterious errors in gdb.  if you don't
supply the shared libs for the specific remote machine you're
using, gdb will appear to work, but it will fail to do some
things correctly, and there's no simple way of finding out what
the problem is if you don't already know the answer.

two example mysterious errors:
  'break printf' fails with a message like 'Can't access memory
    at address ...'
  'print "hi"' segfaults in a strange location.

maybe setting the default solib-absolute-prefix to something like
'[[please set solib-absolute-prefix]]' would be helpful when
there isn't a sensible default.
--

Re: gdbserver, sysroot, prelink

[Daniel Jacobowitz]

On Mon, Oct 04, 2004 at 12:00:03PM -0700, Felix Lee wrote:
> Daniel Jacobowitz <drow@false.org>:
> > How does this make --with-sysroot useless?  That's exactly what sysroot
> > is supposed to do - point it where you keep the exact libraries of the
> > machine.  I usually point it to an NFS server.
> 
> doesn't that assume you only have one such target machine in your
> installation?

I have a different sysroot for each target machine.  They use NFS to
root from the host I run GDB on.  Otherwise, I copy the libraries to
the target.

> maybe setting the default solib-absolute-prefix to something like
> '[[please set solib-absolute-prefix]]' would be helpful when
> there isn't a sensible default.

If there isn't a sensible default for your environment, perhaps you
should give a nonexistant directory for --with-sysroot...

-- 
Daniel Jacobowitz

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> T1 GDB 7.0 has MI10 (official)
> T2 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X1 )
> T3 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X2 )
> T4 GDB 7.1 has MI11 (official)

why would that happen?  I expect 'create a new MI version' to be
basically an atomic change.  like, someone experiments with MI11
on a branch, then merges it into the trunk when it's stable and
tests reasonable cleanly.

if the incompatible change is simple enough to be done in the
trunk, then updating the version and the testsuite should be part
of the same commit.
--

Re: GDB/MI snapshots between major release's

[Daniel Jacobowitz]

On Mon, Oct 04, 2004 at 01:53:57PM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > T1 GDB 7.0 has MI10 (official)
> > T2 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X1 )
> > T3 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X2 )
> > T4 GDB 7.1 has MI11 (official)
> 
> why would that happen?  I expect 'create a new MI version' to be
> basically an atomic change.  like, someone experiments with MI11
> on a branch, then merges it into the trunk when it's stable and
> tests reasonable cleanly.
> 
> if the incompatible change is simple enough to be done in the
> trunk, then updating the version and the testsuite should be part
> of the same commit.

Except that's not how it's done.  Someone else explained how the
version numbers work upthread - the latest one may be evolving.

-- 
Daniel Jacobowitz

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 01:53:57PM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > T1 GDB 7.0 has MI10 (official)
> > T2 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X1 )
> > T3 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X2 )
> > T4 GDB 7.1 has MI11 (official)
> 
> why would that happen?  I expect 'create a new MI version' to be
> basically an atomic change.  like, someone experiments with MI11
> on a branch, then merges it into the trunk when it's stable and
> tests reasonable cleanly.

This is frustrating to me, does anyone understand the problem that I am
describing? Maybe it could be said in a better way.

Basically, a given GDB (from an official release) supports several MI protocols.
A given GDB from a CVS snapshot supports several MI protocols and 1
unsupported protocol.

The 1 unsupported protocol is the problem. 

During development, the first incompatible change forces the MI version
number to be bumped. Every incompatible change after that does not
effect the MI version number. Only after the release can the number be
bumped again (as far as I understand it).

Once the development GDB reaches maturity and becomes an official release, 
the development protocol becomes an official protocol. That new MI protocol could
consist of say 10 incompatible changes with it's predecessor.

Any CVS snapshot after the first incompatible change (version bump) and
before the release will have GDB talking an MI protocol that is not
supported by anyone. It is a development protocol that should never be
used.

I am saying that I need to know if GDB is communicating with one of
these development MI protocols, because I want to use the last official
MI protocol, not a development MI protocol.

Do you understand?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Fabian Cenedese]

At 17:27 04.10.2004 -0400, Bob Rossi wrote:
>On Mon, Oct 04, 2004 at 01:53:57PM -0700, Felix Lee wrote:
>> why would that happen?  I expect 'create a new MI version' to be
>> basically an atomic change.  like, someone experiments with MI11
>> on a branch, then merges it into the trunk when it's stable and
>> tests reasonable cleanly.
>
>This is frustrating to me, does anyone understand the problem that I am
>describing? Maybe it could be said in a better way.

I do, though I haven't a solution either.

>Basically, a given GDB (from an official release) supports several MI protocols.
>A given GDB from a CVS snapshot supports several MI protocols and 1
>unsupported protocol.
>
>The 1 unsupported protocol is the problem. 

One thing that could be added is that -i mi doesn't mean the last one (like mi2 now)
but the last official one. So if there will be a mi3 in progress mi will still select mi2.
Like that you will always be using the last stable protocol. And others can work
with the development version by calling -i mi3. But that won't solve your problem
of knowing what mi version the last stable really is.

>During development, the first incompatible change forces the MI version
>number to be bumped. Every incompatible change after that does not
>effect the MI version number. Only after the release can the number be
>bumped again (as far as I understand it).

The release would be the point where -i mi changes from mi2 to mi3.

>I am saying that I need to know if GDB is communicating with one of
>these development MI protocols, because I want to use the last official
>MI protocol, not a development MI protocol.

To take your example:

gdb --mi-protocols
 mi1
*mi2
 mi3

which means that mi2 is the default (and therefore last stable) mi version. Like
that you get all the necessary info about available and stable versions at once.

bye  Fabi

Re: probing GDB for MI versions

[Eli Zaretskii]

> Date: Mon, 4 Oct 2004 09:12:52 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: gdb@sources.redhat.com
> 
> Yes, I understand, that was my first idea. However, you can see that
> it is a "catch 22". If you do not know what version of MI to start GDB
> with, than you can not understand how to parse the output of the MI
> commands.

I don't see any catch: the output of this specific command could be
made very simple so that it will not need any parsing, just some
trivial string matching or at most regexps.

You will need similar machinery for parsing the output of the
command-line switch you suggested.

> > To solve that, a front end that is willing to support old versions of
> > GDB will need to have a database of old GDB versions and the MI
> > versions they supported.  
> 
> I don't see what the GDB versions have to do with, am I missing
> something? I am only interested in the MI versions.

New MI versions always come with new GDB versions, right?

Re: GDB/MI snapshots between major release's

[Eli Zaretskii]

> Date: Tue, 05 Oct 2004 08:59:32 +0200
> From: Fabian Cenedese <Cenedese@indel.ch>
> 
> One thing that could be added is that -i mi doesn't mean the last
> one (like mi2 now) but the last official one. So if there will be a
> mi3 in progress mi will still select mi2.  Like that you will always
> be using the last stable protocol. And others can work with the
> development version by calling -i mi3. But that won't solve your
> problem of knowing what mi version the last stable really is.

Knowing which MI version is the last stable one is important, but it's
a separate issue.  Do we all agree that for official GDB releases the
problem of MI versions is solved by the features that we already have,
or do someone think that a feature that reports supported MI versions
is still needed even for the official releases?  Let's solve the
situation with official releases first, and get to the development
versions later.

As for the problem with development versions, I think it's part of a
larger problem: how can one know that a certain snapshot is stable
enough to make it available to users?  The stability of MI is a
relatively small aspect of this larger problem, and there's always the
solution suggested by Jason (I think): use the latest stable version
of MI, the one released with the last official GDB version.

Re: GDB/MI snapshots between major release's

[Eli Zaretskii]

> Date: Mon, 4 Oct 2004 11:58:05 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: eliz@gnu.org, gdb@sources.redhat.com
> 
> OK, this is good news. So basically, even thought the MI version is
> bumped it is still not official. Meaning, at that point, if I updated my
> front end to be compatible with the new MI protocol version, there could
> still be another incompatible change before the release. Meaning, I
> would have to wait for the release to get the use out of that new
> version. This is OK with me as long as,
> 
>    - I can have the --mi-protocols command line switch that tells me 
>    what version of GDB/MI protocol is officially supported.
> 
>    - This command line switch only has MI protocols added to it when the 
>    MI protocols become official ( for a release )

We could do that, but I still think an MI command is a better vehicle
for such a feature.

> Is this your view or the view of GDB/MI's maintainers also?

I'm not an MI maintainer, but I fully agree with Mark, FWIW.

Re: probing GDB for MI versions

[Bob Rossi]

On Tue, Oct 05, 2004 at 10:59:37AM +0200, Eli Zaretskii wrote:
> > Date: Mon, 4 Oct 2004 09:12:52 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: gdb@sources.redhat.com
> > 
> > Yes, I understand, that was my first idea. However, you can see that
> > it is a "catch 22". If you do not know what version of MI to start GDB
> > with, than you can not understand how to parse the output of the MI
> > commands.
> 
> I don't see any catch: the output of this specific command could be
> made very simple so that it will not need any parsing, just some
> trivial string matching or at most regexps.

IMHO, it doesn't matter how easy it is to parse the MI output, it should
be done algorithmically. Simple or complicated, the same MI output
parser that parses the entire MI output syntax should be capable of
parsing the command we are suggesting.

The goal is to find out what versions of MI GDB supports so that you can
start GDB up in the highest compatible mode. Right?

How can you start GDB up in MI mode to ask it for the MI versions it
supports? You don't know what MI modes it supports, so you can not start
it in MI mode. That's the catch 22.

> You will need similar machinery for parsing the output of the
> command-line switch you suggested.

Yes, I understand that adding a new command line switch is not the
greatest idea. However, it is the only thing I can think of that allows
a front end to ask GDB what versions of MI it supports, without actually 
needing to know anything about the MI, avoiding the catch 22.

Yes I agree that the output of this command line switch could never
really change, that seems like a pretty negitive point.

> > > To solve that, a front end that is willing to support old versions of
> > > GDB will need to have a database of old GDB versions and the MI
> > > versions they supported.  
> > 
> > I don't see what the GDB versions have to do with, am I missing
> > something? I am only interested in the MI versions.
> 
> New MI versions always come with new GDB versions, right?

I understand now, I think it would be impossible to figure out what 
"GDB version" a GDB CVS snapshot is, do you agree? So there would be no
way to use a database.

Thanks,
Bob Rossi

Re: gdbserver, sysroot, prelink

[Andrew Cagney]

> On Mon, Oct 04, 2004 at 12:00:03PM -0700, Felix Lee wrote:
> 
>>> Daniel Jacobowitz <drow@false.org>:
>>
>>>> > How does this make --with-sysroot useless?  That's exactly what sysroot
>>>> > is supposed to do - point it where you keep the exact libraries of the
>>>> > machine.  I usually point it to an NFS server.

Is there a command to change this (testcase, doco)?  I guess the lack of 
a command is the reason for not having it always enabled.

(Hmm, I wonder, did GDB check that the shlibs it was loading were 
compatible with the main executable?)

Andrew

>>> doesn't that assume you only have one such target machine in your
>>> installation?
> 
> 
> I have a different sysroot for each target machine.  They use NFS to
> root from the host I run GDB on.  Otherwise, I copy the libraries to
> the target.
> 
> 
>>> maybe setting the default solib-absolute-prefix to something like
>>> '[[please set solib-absolute-prefix]]' would be helpful when
>>> there isn't a sensible default.
> 
> 
> If there isn't a sensible default for your environment, perhaps you
> should give a nonexistant directory for --with-sysroot...
> 
> -- Daniel Jacobowitz 

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Tue, Oct 05, 2004 at 11:06:59AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 05 Oct 2004 08:59:32 +0200
> > From: Fabian Cenedese <Cenedese@indel.ch>
> > 
> > One thing that could be added is that -i mi doesn't mean the last
> > one (like mi2 now) but the last official one. So if there will be a
> > mi3 in progress mi will still select mi2.  Like that you will always
> > be using the last stable protocol. And others can work with the
> > development version by calling -i mi3. But that won't solve your
> > problem of knowing what mi version the last stable really is.
> 
> Knowing which MI version is the last stable one is important, but it's
> a separate issue.  Do we all agree that for official GDB releases the
> problem of MI versions is solved by the features that we already have,
> or do someone think that a feature that reports supported MI versions
> is still needed even for the official releases?  Let's solve the
> situation with official releases first, and get to the development
> versions later.

I didn't think there was a problem with using a GDB stable version MI
protocol. This I expected to work the way the documentation described.
I started this thread to figure out how to deal with development
versions which were a side effect of using CVS snapshot's of GDB.

However, I still think that it is necessary to know the supported MI
versions, if the GDB is a stable or a development version.
I started the thread, 
"probing GDB for MI versions"
http://sources.redhat.com/ml/gdb/2004-10/msg00027.html
to resolve this issue (you obviously already know about this, but other
people might not)

It is a requirement of the front end to figure out the highest common MI
protocol that both it and GDB speek. This needs to be done before any
communication can occur between GDB and the front end.

> As for the problem with development versions, I think it's part of a
> larger problem: how can one know that a certain snapshot is stable
> enough to make it available to users?  

I do not know how to answer this question, and I assume that using a CVS
snapshot means that the MI protocol is under development and that it
should not be used.

> The stability of MI is a
> relatively small aspect of this larger problem, and there's always the
> solution suggested by Jason (I think): use the latest stable version
> of MI, the one released with the last official GDB version.

This seems like a good idea to me. I think that we have come to the
conclusion that the cutting edg MI protocol that comes with a CVS snapshots 
of GDB should not be used. It is essential that the front end can figure
out the last stable version of MI that was supported.

Bob Rossi

Re: gdbserver, sysroot, prelink

[Daniel Jacobowitz]

On Tue, Oct 05, 2004 at 08:47:43AM -0400, Andrew Cagney wrote:
> >On Mon, Oct 04, 2004 at 12:00:03PM -0700, Felix Lee wrote:
> >
> >>>Daniel Jacobowitz <drow@false.org>:
> >>
> >>>>> How does this make --with-sysroot useless?  That's exactly what 
> >>>>sysroot
> >>>>> is supposed to do - point it where you keep the exact libraries of the
> >>>>> machine.  I usually point it to an NFS server.
> 
> Is there a command to change this (testcase, doco)?  I guess the lack of 
> a command is the reason for not having it always enabled.

All --with-sysroot does is add some fancy logic for setting
solib-absolute-prefix.  Without it, the default is "", which is correct
for native debugging.  That's why it's not always enabled.

You can override it just by setting solib-absolute-prefix.

> (Hmm, I wonder, did GDB check that the shlibs it was loading were 
> compatible with the main executable?)

No, it doesn't.  That's a little tricky...

-- 
Daniel Jacobowitz

Re: gdbserver, sysroot, prelink

[Felix Lee]

Daniel Jacobowitz <drow@false.org>:
> All --with-sysroot does is add some fancy logic for setting
> solib-absolute-prefix.  Without it, the default is "", which is correct
> for native debugging.  That's why it's not always enabled.

how about making the default something nonexistent when
host!=target and --with-sysroot isn't specified?
--

Re: GDB/MI snapshots between major release's

[Daniel Jacobowitz]

On Tue, Oct 05, 2004 at 11:14:44AM +0200, Eli Zaretskii wrote:
> > Date: Mon, 4 Oct 2004 11:58:05 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: eliz@gnu.org, gdb@sources.redhat.com
> > 
> > OK, this is good news. So basically, even thought the MI version is
> > bumped it is still not official. Meaning, at that point, if I updated my
> > front end to be compatible with the new MI protocol version, there could
> > still be another incompatible change before the release. Meaning, I
> > would have to wait for the release to get the use out of that new
> > version. This is OK with me as long as,
> > 
> >    - I can have the --mi-protocols command line switch that tells me 
> >    what version of GDB/MI protocol is officially supported.
> > 
> >    - This command line switch only has MI protocols added to it when the 
> >    MI protocols become official ( for a release )
> 
> We could do that, but I still think an MI command is a better vehicle
> for such a feature.

I think using a command line switch makes sense.  You're going to have
to restart GDB to change MI protocols anyway, so why force the user to
go into MI?

I also like the idea of listing non-MI (which right now means annotate)
protocols in the same output.

-- 
Daniel Jacobowitz

Re: probing GDB for MI versions

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I understand now, I think it would be impossible to figure out what 
> "GDB version" a GDB CVS snapshot is, do you agree? So there would be no
> way to use a database.

every day there's an automatic increment of the version string in
CVS.  currently it's '2004-10-05-cvs'.  anyone making a snapshot
will have that as a version string, or they'll change it to
something that's hopefully unique.  there's still 1 day of fuzz,
so it's not a perfect identifier of gdb version, since there's no
particular guarantee that a snapshot will be taken at the same
time as the version change.

http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/version.in?cvsroot=src
--

Bumping MI protocol

[Bob Rossi]

Hi,

I am wondering when the MI protocol gets bumped. Besides an MI command
that has been changed in an incompatible way, or the actual MI output
syntax changing, does the MI version get bumped for other reasons?

For example, say a new mi command gets added to version 5. Does the mi
version then become 6 because a new command has been added? 

Or does MI5 at one major release have X MI commands available, and MI5
at another major release have Y MI commands available?

Can the conditions for bumping the MI version be enumerated?
Can this information be documented for all to easily understand?

Can a front end developer find all of the functions available to a
specific version of an MI protocol from the documentation?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Tue, Oct 05, 2004 at 10:07:36AM -0400, Daniel Jacobowitz wrote:
> On Tue, Oct 05, 2004 at 11:14:44AM +0200, Eli Zaretskii wrote:
> > > Date: Mon, 4 Oct 2004 11:58:05 -0400
> > > From: Bob Rossi <bob@brasko.net>
> > > Cc: eliz@gnu.org, gdb@sources.redhat.com
> > > 
> > > OK, this is good news. So basically, even thought the MI version is
> > > bumped it is still not official. Meaning, at that point, if I updated my
> > > front end to be compatible with the new MI protocol version, there could
> > > still be another incompatible change before the release. Meaning, I
> > > would have to wait for the release to get the use out of that new
> > > version. This is OK with me as long as,
> > > 
> > >    - I can have the --mi-protocols command line switch that tells me 
> > >    what version of GDB/MI protocol is officially supported.
> > > 
> > >    - This command line switch only has MI protocols added to it when the 
> > >    MI protocols become official ( for a release )
> > 
> > We could do that, but I still think an MI command is a better vehicle
> > for such a feature.
> 
> I think using a command line switch makes sense.  You're going to have
> to restart GDB to change MI protocols anyway, so why force the user to
> go into MI?
> 
> I also like the idea of listing non-MI (which right now means annotate)
> protocols in the same output.

Have we come to a resolution that a command like this is necessary? 

I basically need it to query GDB to determine what MI versions it
officially supports.

It would satisfy my needs from GDB, but what about others?

Bob Rossi

Re: Bumping MI protocol

[Nathan J. Williams]

Bob Rossi <bob@brasko.net> writes:

> I am wondering when the MI protocol gets bumped. Besides an MI command
> that has been changed in an incompatible way, or the actual MI output
> syntax changing, does the MI version get bumped for other reasons?

I'd just like to point out that these questions all seem, to a
not-very-inside observer, highly hypothetical. There's been few enough
revisions of MI (currently on v2?) that the scenarios you want
detailed descriptions of and rules for have generally not come up, and
this (volunteer) community doesn't seem to take kindly to prescriptive
legislation in such areas.

        - Nathan

Re: probing GDB for MI versions

[Eli Zaretskii]

> Date: Tue, 5 Oct 2004 08:11:36 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: g@white, gdb@sources.redhat.com

[Could you please remove that "g@white" from the CC list?  It bounces,
so I need to manually remove it, which is a pain, as I respond to too
many mails daily to afford editing the headers.  If you need that for
your purposes, please use Bcc.]

> > I don't see any catch: the output of this specific command could be
> > made very simple so that it will not need any parsing, just some
> > trivial string matching or at most regexps.
> 
> IMHO, it doesn't matter how easy it is to parse the MI output, it should
> be done algorithmically. Simple or complicated, the same MI output
> parser that parses the entire MI output syntax should be capable of
> parsing the command we are suggesting.

That's a given.  What I meant to say was that the output of this
command could be so simple (e.g., a simple string with no structure)
that every MI parser would understand that.  Thus no catch-22.

> The goal is to find out what versions of MI GDB supports so that you can
> start GDB up in the highest compatible mode. Right?
> 
> How can you start GDB up in MI mode to ask it for the MI versions it
> supports? You don't know what MI modes it supports, so you can not start
> it in MI mode. That's the catch 22.

Again, I see no catch.  Here's what I had in mind:

  foo$ gdb -interpreter=mi
  [the starting blurb omitted]
  (gdb) -mi-version
  mi3

After this, the front end could either (1) quit GDB and restart it
with a "-interpreter=mi2" (say) switch, or (2) modify its parsing to
adapt to MI version 3.

In other words, I don't need to know what MI versions GDB supports to
start it in MI mode.

> > New MI versions always come with new GDB versions, right?
> 
> I understand now, I think it would be impossible to figure out what 
> "GDB version" a GDB CVS snapshot is, do you agree? So there would be no
> way to use a database.

Someone else already replied to this: the development snapshots do
have a unique version string, which does allow for a database,
although making the database work for snapshots would require some
support code (because you don't want to have an entry for each day
between official releases).

Re: GDB/MI snapshots between major release's

[Eli Zaretskii]

> Date: Tue, 5 Oct 2004 10:07:36 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Bob Rossi <bob@brasko.net>, kettenis@gnu.org, gdb@sources.redhat.com
> 
> I think using a command line switch makes sense.  You're going to have
> to restart GDB to change MI protocols anyway, so why force the user to
> go into MI?

First, it is possible that when the front end knows which MI version
is the last stable one, it will not need to restart GDB, but just
arrange for the appropriate parser to be used for the rest of the
session.

And second, even if you do need to restart, it makes sense to have
this command in the MI so that the same parser could be used to do
the job of finding the MI version(s) as well, instead of having a
special code that parses the ouput of a command-line option.

A downside of the command-line option that I very much don't like is
that command-line options are mainly for the human users and are
documented in a special section that describes how to run GDB, not how
to use the MI interpreter.

> I also like the idea of listing non-MI (which right now means annotate)
> protocols in the same output.

Does some front end need that?  If not, why introduce unneeded
generalizations?  I actually think that the output of the feature we
are discussing needs to be a single string: the latest version of MI
supported by this GDB that is known to be stable.  Given that info,
the front end should be able to figure out all the stable versions it
can use: they are those whose version numbers are below the latest
stable one.

Re: Bumping MI protocol

[Bob Rossi]

On Tue, Oct 05, 2004 at 10:59:46PM -0400, Nathan J. Williams wrote:
> Bob Rossi <bob@brasko.net> writes:
> 
> > I am wondering when the MI protocol gets bumped. Besides an MI command
> > that has been changed in an incompatible way, or the actual MI output
> > syntax changing, does the MI version get bumped for other reasons?
> 
> I'd just like to point out that these questions all seem, to a
> not-very-inside observer, highly hypothetical. There's been few enough
> revisions of MI (currently on v2?) that the scenarios you want
> detailed descriptions of and rules for have generally not come up, and
> this (volunteer) community doesn't seem to take kindly to prescriptive
> legislation in such areas.

Exscuse me for being frank, your statements about this question are foolish.

I would like to know if the MI version get's bumped for adding new MI
commands. This is directly related to the implementation of a front end.
Nathan, how could a front end implement an MIX protocol if it doesn't
know what functions that protocol provides?

Bob Rossi

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Wed, Oct 06, 2004 at 12:15:40PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 5 Oct 2004 10:07:36 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Bob Rossi <bob@brasko.net>, kettenis@gnu.org, gdb@sources.redhat.com
> > 
> > I think using a command line switch makes sense.  You're going to have
> > to restart GDB to change MI protocols anyway, so why force the user to
> > go into MI?
> 
> First, it is possible that when the front end knows which MI version
> is the last stable one, it will not need to restart GDB, but just
> arrange for the appropriate parser to be used for the rest of the
> session.

This is not correct. The front end has parsers for different versions of
GDB's MI protocol. The parser for MI2 will not work for the MI3 protocol
The front end *can not* start up GDB just by using -interpreter=mi
because it doesn't know what parser to use in this situation.
Can we agree on this point for starters?

This is why there needs to be a non-MI command to figure out what MI
versions the current GDB supports.

> A downside of the command-line option that I very much don't like is
> that command-line options are mainly for the human users and are
> documented in a special section that describes how to run GDB, not how
> to use the MI interpreter.

Yes, this is a downside, but I don't think your MI solution is quite
ready for use, however, maybe we could come up with something better
still.

> > I also like the idea of listing non-MI (which right now means annotate)
> > protocols in the same output.
> 
> Does some front end need that?  If not, why introduce unneeded
> generalizations?  

Yes, of course they do :)
xxgdb, ddd, gvd, ...
They all use annotations and they all assume annotate 1 is around. As
soon as you pull annotate 1, they will all have the same problem.

Emacs uses annotate 1, probably annotate 2 at some version and now
annotate 3 at some version. Also, I believe it's moving into the MI
realm .... what a mess ...

> I actually think that the output of the feature we
> are discussing needs to be a single string: the latest version of MI
> supported by this GDB that is known to be stable.  Given that info,
> the front end should be able to figure out all the stable versions it
> can use: they are those whose version numbers are below the latest
> stable one.

This is wrong. I *need* the output to have *all* the versions of MI that
the current GDB supports. I need this for a very very simple reason. I
need to make sure that my front ends that don't support the current
official release of GDB can start GDB in the highest mode it supports.

If at some point, GDB decides not to honor MI2 anymore, I need to make
sure that I know that. If my front end only supports MI2, and GDB
supports only MI3, than the function you are suggesting will not be good
enough for me.

Bob Rossi

Re: probing GDB for MI versions

[Bob Rossi]

On Wed, Oct 06, 2004 at 11:57:56AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 5 Oct 2004 08:11:36 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: g@white, gdb@sources.redhat.com
> 
> [Could you please remove that "g@white" from the CC list?  It bounces,
> so I need to manually remove it, which is a pain, as I respond to too
> many mails daily to afford editing the headers.  If you need that for
> your purposes, please use Bcc.]

Yes, I'm sorry about that.

> > > I don't see any catch: the output of this specific command could be
> > > made very simple so that it will not need any parsing, just some
> > > trivial string matching or at most regexps.
> > 
> > IMHO, it doesn't matter how easy it is to parse the MI output, it should
> > be done algorithmically. Simple or complicated, the same MI output
> > parser that parses the entire MI output syntax should be capable of
> > parsing the command we are suggesting.
> 
> That's a given.  What I meant to say was that the output of this
> command could be so simple (e.g., a simple string with no structure)
> that every MI parser would understand that.  Thus no catch-22.

Unfortunately this topic is on two different threads. I feel badly that I
am wasting your time here with bad descriptions of the "catch-22". This
is to help make my opinion clear on why it is a "catch-22" and not
possible.

   The front end has parsers for different versions of GDB's MI protocol. 
   The parser for MI2 may not work for the MI3 protocol.
   The parser for the MI3 protocol may not work for the MI2 protocol.
   The front end *can not* start up GDB just by using -interpreter=mi
   because it doesn't know what parser to use in this situation.
   Can we agree on this point for starters?

For instance, if in MI3, the MI output syntax was changed to add a
label for each MI output command to tell the front end what type of
command is being transmitted, or if any incompatible change was added
to the output syntax, than the parser for MI2 and MI3 would not work
with each other.

In this case alone, the front end can not start up GDB with a specific
version of MI. It needs to get from GDB the versions of MI that it
supports, and then start it up in the highest compatible mode.

This is why there needs to be a non-MI command to figure out what MI
versions the current GDB supports. It is also why I am claiming that
there is a catch-22.

> > The goal is to find out what versions of MI GDB supports so that you can
> > start GDB up in the highest compatible mode. Right?
> > 
> > How can you start GDB up in MI mode to ask it for the MI versions it
> > supports? You don't know what MI modes it supports, so you can not start
> > it in MI mode. That's the catch 22.
> 
> Again, I see no catch.  Here's what I had in mind:
> 
>   foo$ gdb -interpreter=mi
>   [the starting blurb omitted]
>   (gdb) -mi-version
>   mi3
> 
> After this, the front end could either (1) quit GDB and restart it
> with a "-interpreter=mi2" (say) switch, or (2) modify its parsing to
> adapt to MI version 3.

If I am proven to be wrong above, then this would be fine with me.

Bob Rossi

RE: probing GDB for MI versions

[Dave Korn]

> -----Original Message-----
> From: gdb-owner On Behalf Of Bob Rossi
> Sent: 06 October 2004 12:39

> Unfortunately this topic is on two different threads. I feel 
> badly that I
> am wasting your time here with bad descriptions of the 
> "catch-22". This
> is to help make my opinion clear on why it is a "catch-22" and not
> possible.
> 
>    The front end has parsers for different versions of GDB's 
> MI protocol. 
>    The parser for MI2 may not work for the MI3 protocol.
>    The parser for the MI3 protocol may not work for the MI2 protocol.
>    The front end *can not* start up GDB just by using -interpreter=mi
>    because it doesn't know what parser to use in this situation.
>    Can we agree on this point for starters?

  No, we can't.  As long as the output from the -mi-version MI command stays
in the same format, you can always parse that and determine which version to
use.  Everything else can change.  You can start up with an utterly minimal,
unintelligent parser, that knows nothing except how to send a -mi-version
command and parse the output; that parser can then direct one of your
version-dependent parsers to take over.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Bumping MI protocol

[Eli Zaretskii]

> Date: Wed, 6 Oct 2004 07:14:36 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: GDB <gdb@sources.redhat.com>
> 
> Exscuse me for being frank, your statements about this question are foolish.

I, for one, don't think Nathan's comments are foolish.  As a volunteer
project, we shouldn't waste too much time discussing hypothetical
issues.

> Nathan, how could a front end implement an MIX protocol if it doesn't
> know what functions that protocol provides?

No one requires a front end to implement support for features that are
introduced by GDB versions released after the front end is released.
The only way for a front end to support new features is to track GDB
development, and check the GDB and MI versions to know what commands
are safe to use.

Put it differently, even if the MI version would be incremented each
time a new command is added (which IMHO would be an unwise policy),
you would need an update for the front end to support that command.

Re: GDB/MI snapshots between major release's

[Eli Zaretskii]

> Date: Wed, 6 Oct 2004 07:27:03 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: Daniel Jacobowitz <drow@false.org>, gdb@sources.redhat.com
> 
> > First, it is possible that when the front end knows which MI version
> > is the last stable one, it will not need to restart GDB, but just
> > arrange for the appropriate parser to be used for the rest of the
> > session.
> 
> This is not correct. The front end has parsers for different versions of
> GDB's MI protocol. The parser for MI2 will not work for the MI3 protocol

In general, it won't, but for a very specific case of _a_single_command_,
it could very well do.  Obviously, we will need to agree to _never_ 
change the syntax of the output of that command once it is introduced,
but that is all we need to do to make sure _every_ MI parser henceforth
will understand that command's output.

> The front end *can not* start up GDB just by using -interpreter=mi
> because it doesn't know what parser to use in this situation.
> Can we agree on this point for starters?

Obviously, I disagree: if the syntax of what that command outputs does
not change, you should be able to use _any_ MI parser that knows about
this command; in particularly, the latest MI parser will do, so
invoking GDB with "-interpreter=mi" will solve the problem.  Can we
agree on this point?

> > > I also like the idea of listing non-MI (which right now means annotate)
> > > protocols in the same output.
> > 
> > Does some front end need that?  If not, why introduce unneeded
> > generalizations?  
> 
> Yes, of course they do :)
> xxgdb, ddd, gvd, ...
> They all use annotations and they all assume annotate 1 is around. As
> soon as you pull annotate 1, they will all have the same problem.

So how these front ends solve this problem now?

> > I actually think that the output of the feature we
> > are discussing needs to be a single string: the latest version of MI
> > supported by this GDB that is known to be stable.  Given that info,
> > the front end should be able to figure out all the stable versions it
> > can use: they are those whose version numbers are below the latest
> > stable one.
> 
> This is wrong. I *need* the output to have *all* the versions of MI that
> the current GDB supports. I need this for a very very simple reason. I
> need to make sure that my front ends that don't support the current
> official release of GDB can start GDB in the highest mode it supports.

I still don't see the problem, sorry.  Your front end surely knows (or
can know) what is the latest MI version it supports, right?  If so,
the following simple algorithm should do what you want:

  get the latest stable MI version from GDB, call it $mi-ver
  if $mi-ver is greater than N, the latest MI version supported by the front-end
    then restart GDB with "-interpreter=miN"
    else either set up to use the parser for $mi-ver
         or restart GDB with "-interpreter=mi"
  endif

What am I missing?

> If at some point, GDB decides not to honor MI2 anymore, I need to make
> sure that I know that. If my front end only supports MI2, and GDB
> supports only MI3, than the function you are suggesting will not be good
> enough for me.

If that happens, invoking GDB with "-interpreter=mi2" will exit with a
failure status and print an error message.  That should be enough for
the front end to say that it cannot work with such a GDB, if MI2 is
the only MI version the front end understands.  Still no problem that
I see; do you?

Re: probing GDB for MI versions

['Bob Rossi']

On Wed, Oct 06, 2004 at 12:50:34PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: gdb-owner On Behalf Of Bob Rossi
> > Sent: 06 October 2004 12:39
> 
> > Unfortunately this topic is on two different threads. I feel 
> > badly that I
> > am wasting your time here with bad descriptions of the 
> > "catch-22". This
> > is to help make my opinion clear on why it is a "catch-22" and not
> > possible.
> > 
> >    The front end has parsers for different versions of GDB's 
> > MI protocol. 
> >    The parser for MI2 may not work for the MI3 protocol.
> >    The parser for the MI3 protocol may not work for the MI2 protocol.
> >    The front end *can not* start up GDB just by using -interpreter=mi
> >    because it doesn't know what parser to use in this situation.
> >    Can we agree on this point for starters?
> 
>   No, we can't.  As long as the output from the -mi-version MI command stays
> in the same format, you can always parse that and determine which version to
> use.  

Dave, you do not understand the problem at all. I do not appreciate your
defininative answer, especially since it is incorrect.

The actual MI output syntax is capable of changing between MI versions.
If the MI4 output syntax (grammar) has an incompatible change with MI3,
then 
   * the MI3 parser will not even be capable of parsing and building a 
     parse tree for the MI4 protocol.
   * the MI4 parser will not even be capable of parsing and building a
     parse tree for the MI3 protocol.

It is not possible to understand the output of the command no matter how
simple it is. If there is no parse tree, then there is no way to
understand the output from GDB.

> Everything else can change.  You can start up with an utterly minimal,
> unintelligent parser, that knows nothing except how to send a -mi-version
> command and parse the output; that parser can then direct one of your
> version-dependent parsers to take over.

I don't understand the concept of an "utterly minimal unintelligent parser". 
That is rediculous. I am generating a parser from the grammar.

There absolutly needs to be a way for the front end to ask GDB what
versions of the MI protocol it supports. 

There is no way the front end can ask GDB what protocols it supports if
it needs to talk to it with an MI protocol. Understood?

Bob Rossi

Re: Bumping MI protocol

[Bob Rossi]

On Wed, Oct 06, 2004 at 02:10:09PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 6 Oct 2004 07:14:36 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: GDB <gdb@sources.redhat.com>
> > 
> > Exscuse me for being frank, your statements about this question are foolish.
> 
> I, for one, don't think Nathan's comments are foolish.  As a volunteer
> project, we shouldn't waste too much time discussing hypothetical
> issues.

Either one of you, please describe to me which of these questions is
foolish, and I will clearly explain to you why I need to know this
information in order to build a front end.

1. Besides an MI command that has been changed in an incompatible way, 
   or the actual MI output syntax changing, does the MI version get 
   bumped for other reasons?

2. Can the conditions for bumping the MI version be enumerated?

3. Can this information be documented for all to easily understand?

4. Can a front end developer find all of the functions available to a
   specific version of an MI protocol from the documentation?

> > Nathan, how could a front end implement an MIX protocol if it doesn't
> > know what functions that protocol provides?
> 
> No one requires a front end to implement support for features that are
> introduced by GDB versions released after the front end is released.
> The only way for a front end to support new features is to track GDB
> development, and check the GDB and MI versions to know what commands
> are safe to use.
> 
> Put it differently, even if the MI version would be incremented each
> time a new command is added (which IMHO would be an unwise policy),
> you would need an update for the front end to support that command.

I also do not think it would be a good idea to bump the version because
of new commands. I am asking because it's not documented anywhere. If
you want the questions to stop, maybe you will see that there is not
enough information avaiable for front end developers to figure these
thngs out.

Thanks,
Bob Rossi

Re: Bumping MI protocol

[Nathan J. Williams]

Bob Rossi <bob@brasko.net> writes:

> Either one of you, please describe to me which of these questions is
> foolish, and I will clearly explain to you why I need to know this
> information in order to build a front end.

That you need to know this information, or think you need to know this
information, does not imply that it exists. I'm suggesting that MI is
young and unevolved enough that there is no serious body of work in
woking with its evolution. This means that your questions of "What
happens in case X?" are effectively "please spend time deciding what
happens in case X, which has not yet occurred." To put it in other
terms, an unfunded mandate.

I think you'll make much more ground by assuming that none of these
questions have answers, and proposing possible answers (the "can you
use an MI command to check the MI version" thread seems more
productive to me, for example, because it included suggestions whose
merits can be concretely dissussed).

> I am asking because it's not documented anywhere. If
> you want the questions to stop, maybe you will see that there is not
> enough information avaiable for front end developers to figure these
> thngs out.

Yes, I think such things are not documented because they have not been
considered or they have not come up to be handled, not because of a
conspiracy to keep front-end developers in the dark.

        - Nathan

Re: probing GDB for MI versions

[Nathan J. Williams]

"'Bob Rossi'" <bob@brasko.net> writes:

> It is not possible to understand the output of the command no matter how
> simple it is. If there is no parse tree, then there is no way to
> understand the output from GDB.

You have constrained yourself to using a formal parser for absolutely
all interaction with GDB output. This constraint is unnecessary. The
suggestions in this thread are "start gdb, hand-check the result from
this particular minimal command, and *then* fire up the full-fledged,
grammar-generated parser, selecting appropriately for the version".

Perhaps you can explain why you feel this constraint to be necessary,
since that appears to be the real point of contention.

        - Nathan

Re: probing GDB for MI versions

['Bob Rossi']

On Wed, Oct 06, 2004 at 12:45:49PM -0400, Nathan J. Williams wrote:
> "'Bob Rossi'" <bob@brasko.net> writes:
> 
> > It is not possible to understand the output of the command no matter how
> > simple it is. If there is no parse tree, then there is no way to
> > understand the output from GDB.
> 
> You have constrained yourself to using a formal parser for absolutely
> all interaction with GDB output. This constraint is unnecessary. 

O, I see. 

It is now a formal requirement of the GDB group to have front
ends write a formal parser for each MI version and

it is also a requirement of the GDB group to have front ends write an
"utterly minimal, unintelligent parser"?

> The
> suggestions in this thread are "start gdb, hand-check the result from
> this particular minimal command, and *then* fire up the full-fledged,
> grammar-generated parser, selecting appropriately for the version".
> 
> Perhaps you can explain why you feel this constraint to be necessary,
> since that appears to be the real point of contention.

The whole reason an MI grammar was invented was so that there were no
"utterly minimal, unintelligent parser" nonsense going on in front ends.

I am generating parsers that meet a specification. There is no way I am
interested in writing a "half-fledged" parser to parse the output of an
MI command just to figure out what "full fledged" parser I should use.

This is rediculous and I don't really even consider it an option of
debate.

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Wed, Oct 06, 2004 at 02:26:55PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 6 Oct 2004 07:27:03 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: Daniel Jacobowitz <drow@false.org>, gdb@sources.redhat.com
> > 
> > > First, it is possible that when the front end knows which MI version
> > > is the last stable one, it will not need to restart GDB, but just
> > > arrange for the appropriate parser to be used for the rest of the
> > > session.
> > 
> > This is not correct. The front end has parsers for different versions of
> > GDB's MI protocol. The parser for MI2 will not work for the MI3 protocol
> 
> In general, it won't, but for a very specific case of _a_single_command_,
> it could very well do.  

You obviously not understanding the point here. I can not even get my
front end to the point where it can look at the command. The reason is,
I can not *PARSE* the command. 

Here is a simple explanation that I have tried to discuss over and over.
   
   1. Each version of MI comes with a grammar.
   2. If the MI grammar changes between MI1 and MI2 then
   3. A parser is generated that understands the grammar for MI1
   4. A parser is generated that understands the grammar for MI2
   5. The parser for MI1 *will not parse* the output of MI2
   6. The parser for MI2 *will not parse* the output of MI1

Therefor, I don't have a parse tree, and can not even begin to
understand what MI output command GDB just sent to me. There is no
"specific case", where a front end could understand
"_a_single_command_".

This is a very simple issue I am discussing here and I expect people to
understand what I am saying.

> Obviously, we will need to agree to _never_ 
> change the syntax of the output of that command once it is introduced,
> but that is all we need to do to make sure _every_ MI parser henceforth
> will understand that command's output.

You are ready to guarentee that the MI output syntax (grammar) will
never change? This has nothing to do with the way the MI output command
lists the versions (field names, ... ).

> > The front end *can not* start up GDB just by using -interpreter=mi
> > because it doesn't know what parser to use in this situation.
> > Can we agree on this point for starters?
> 
> Obviously, I disagree: if the syntax of what that command outputs does
> not change, you should be able to use _any_ MI parser that knows about
> this command; in particularly, the latest MI parser will do, so
> invoking GDB with "-interpreter=mi" will solve the problem.  Can we
> agree on this point?

Are you saying that the MI output syntax wil never change? I doubt you
can make this promise.

> > > > I also like the idea of listing non-MI (which right now means annotate)
> > > > protocols in the same output.
> > > 
> > > Does some front end need that?  If not, why introduce unneeded
> > > generalizations?  
> > 
> > Yes, of course they do :)
> > xxgdb, ddd, gvd, ...
> > They all use annotations and they all assume annotate 1 is around. As
> > soon as you pull annotate 1, they will all have the same problem.
> 
> So how these front ends solve this problem now?

They assume annotate 1 is there, since it's 10 years old or so.
If it's not there, you probably will get random results.

> > > I actually think that the output of the feature we
> > > are discussing needs to be a single string: the latest version of MI
> > > supported by this GDB that is known to be stable.  Given that info,
> > > the front end should be able to figure out all the stable versions it
> > > can use: they are those whose version numbers are below the latest
> > > stable one.
> > 
> > This is wrong. I *need* the output to have *all* the versions of MI that
> > the current GDB supports. I need this for a very very simple reason. I
> > need to make sure that my front ends that don't support the current
> > official release of GDB can start GDB in the highest mode it supports.
> 
> I still don't see the problem, sorry.  Your front end surely knows (or
> can know) what is the latest MI version it supports, right?  If so,
> the following simple algorithm should do what you want:
> 
>   get the latest stable MI version from GDB, call it $mi-ver
>   if $mi-ver is greater than N, the latest MI version supported by the front-end
>     then restart GDB with "-interpreter=miN"
>     else either set up to use the parser for $mi-ver
>          or restart GDB with "-interpreter=mi"
>   endif
> 
> What am I missing?

You are missing elegance. It is a "first approach" to start GDB in every
MI mode from the highest one that the front end supports down. It would
be much more elegant to just ask GDB what versions of MI it supported.
As front ends scale, it could have to start GDB 10 times to figure out
what MI protocol it supports, even then, you wouldn't know if it was a
development protocol or not.

> > If at some point, GDB decides not to honor MI2 anymore, I need to make
> > sure that I know that. If my front end only supports MI2, and GDB
> > supports only MI3, than the function you are suggesting will not be good
> > enough for me.
> 
> If that happens, invoking GDB with "-interpreter=mi2" will exit with a
> failure status and print an error message.  That should be enough for
> the front end to say that it cannot work with such a GDB, if MI2 is
> the only MI version the front end understands.  Still no problem that
> I see; do you?

I understand your point here. I still think if we are going to put the
last officially released version, it would just be nice and easy to put
them all.

Thanks,
Bob Rossi

RE: probing GDB for MI versions

[Dave Korn]

> -----Original Message-----
> From: 'Bob Rossi'  
> Sent: 06 October 2004 17:22

> On Wed, Oct 06, 2004 at 12:50:34PM +0100, Dave Korn wrote:
> > > -----Original Message-----
> > > From: gdb-owner On Behalf Of Bob Rossi
> > > Sent: 06 October 2004 12:39

> > >    The front end has parsers for different versions of GDB's 
> > > MI protocol. 
> > >    The parser for MI2 may not work for the MI3 protocol.
> > >    The parser for the MI3 protocol may not work for the 
> MI2 protocol.
> > >    The front end *can not* start up GDB just by using 
> -interpreter=mi
> > >    because it doesn't know what parser to use in this situation.
> > >    Can we agree on this point for starters?
> > 
> >   No, we can't.  As long as the output from the -mi-version 
> MI command stays
> > in the same format, you can always parse that and determine 
> which version to
> > use.  

> Dave, you do not understand the problem at all. I do not 
> appreciate your
> defininative answer, especially since it is incorrect.

#1.  Well, I don't appreciate your rudeness, but hey, we don't always get
what we want in life.  Guess you're just SOL.

#2.  My answer IS correct.  I DO understand the problem, and in fact I
understand it better enough than you do that I can see the very very obvious
solution (that you aren't capable of grasping) as well as the problem
itself.

#3.  Why do you have to be the _only_ person in the entire software industry
who isn't capable of dealing with elementary versioning and compatibility
issues?  These techniques work fine for EVERYONE else but you.

> The actual MI output syntax is capable of changing between MI 
> versions.

  Yes.  I hope we're all agreed that there is no hope of (nor point to)
tracking a work-in-progress as it changes on a day-by-day basis.

> If the MI4 output syntax (grammar) has an incompatible change 
> with MI3,
> then 
>    * the MI3 parser will not even be capable of parsing and 
> building a 
>      parse tree for the MI4 protocol.
>    * the MI4 parser will not even be capable of parsing and building a
>      parse tree for the MI3 protocol.

  Try and think outside the box.  Your over-reliance on tools is hobbling
you.  You aren't obliged by statute to use an automatically generated parser
based on a formal grammar.  You can use printf to send the -mi-version
command to the gdb instance, and you can use sscanf to parse the version
number out of the string "MI version is XXXX" that it returns.

> It is not possible to understand the output of the command no 
> matter how simple it is. 

  Speak for yourself.  I can understand it, it's human readable.  I could
write a very very very simple bit of code using sscanf that would understand
it.  You might have a problem understanding it, but you're the only one who
does, and there's no need for you to.

>If there is no parse tree, then there is no way to
> understand the output from GDB.

  Don't be so facile.  You send one very simple command, get back one very
simple output that you can parse with strcmp or sscanf, for crying out loud.
Then you know what MI version you're dealing with.

> I don't understand the concept of an "utterly minimal 
> unintelligent parser". 

  Well, you're clearly biting off more than you can chew with this entire
project.  As I said above, something of the degree of complexity of a single
sscanf statement is what I mean.

> That is rediculous. I am generating a parser from the grammar.
>
> There absolutly needs to be a way for the front end to ask GDB what
> versions of the MI protocol it supports. 
> 
> There is no way the front end can ask GDB what protocols it 
> supports if
> it needs to talk to it with an MI protocol. Understood?

  I understand what you're claiming, but I gave you a perfectly clear and
simple way of doing it.  You haven't demonstrated any problem with my
proposal, because as you said above, you haven't even understood it yet.
When you do understand it, you'll also understand that it works just fine.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Bumping MI protocol

[Felix Lee]

"Eli Zaretskii" <eliz@gnu.org>:
> > From: Bob Rossi <bob@brasko.net>
> > Exscuse me for being frank, your statements about this question are foolish.
> 
> I, for one, don't think Nathan's comments are foolish.  As a volunteer
> project, we shouldn't waste too much time discussing hypothetical
> issues.

I agree with Eli and Nathan, from a different angle.

I've never tried implementing a gdb front-end, but if I had to do
one, I wouldn't rely on gdb conforming exactly to any particular
specification, because bugs happen, and eliminating all bugs is
not going to happen in my lifetime.

users are unlikely to be happy about restarting a complicated
debugging session when they encounter a bug in the debugger, so a
robust front-end will need to do some sanity checking of the
conversation, and it will also need a method of resynchronizing
the conversation when the sanity checks fail.

if a front-end has this basic adaptability, then it's not that
big a deal if any one-off version of gdb doesn't conform exactly
to spec.  so you can concentrate effort on making things work
well for the versions of gdb that are commonly in use.
--

Re: GDB/MI snapshots between major release's

[Paul Koning]

>>>>> "Bob" == Bob Rossi <bob@brasko.net> writes:

 Bob> On Wed, Oct 06, 2004 at 02:26:55PM +0200, Eli Zaretskii wrote:
 >> > Date: Wed, 6 Oct 2004 07:27:03 -0400 > From: Bob Rossi
 >> <bob@brasko.net> > Cc: Daniel Jacobowitz <drow@false.org>,
 >> gdb@sources.redhat.com
 >> > 
 >> > > First, it is possible that when the front end knows which MI
 >> version > > is the last stable one, it will not need to restart
 >> GDB, but just > > arrange for the appropriate parser to be used
 >> for the rest of the > > session.
 >> > 
 >> > This is not correct. The front end has parsers for different
 >> versions of > GDB's MI protocol. The parser for MI2 will not work
 >> for the MI3 protocol
 >> 
 >> In general, it won't, but for a very specific case of
 >> _a_single_command_, it could very well do.

 Bob> You obviously not understanding the point here. I can not even
 Bob> get my front end to the point where it can look at the
 Bob> command. The reason is, I can not *PARSE* the command.

 Bob> Here is a simple explanation that I have tried to discuss over
 Bob> and over.
   
 Bob> 1. Each version of MI comes with a grammar.  2. If the MI
 Bob> grammar changes between MI1 and MI2 then 3. A parser is
 Bob> generated that understands the grammar for MI1 4. A parser is
 Bob> generated that understands the grammar for MI2 5. The parser for
 Bob> MI1 *will not parse* the output of MI2 6. The parser for MI2
 Bob> *will not parse* the output of MI1

I'm puzzled.  If MI2 is a superset of MI1, then the parser for MI2 by
definition will parse any string in MI1.  And generalizing, unless MI1
and MI2 have essentially nothing in common, I don't see how it can be
true that you cannot parse any command at all.

Just as in any protocol, you need version numbers to cope with the
situation where a new MIx is NOT just a superset of MI<x-1>.  But the
usual picture of protocol evolution is that those cases are not all
that common -- most evoluation creates supersets.

(And incidentally, a version numbering scheme would have to rely on
the restriction that a certain defined part of the protocol is
immutable, or at least allows no changes other than supersetting --
and that part conveys version information.)

     paul

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Wed, Oct 06, 2004 at 12:57:40PM -0400, Paul Koning wrote:
> >>>>> "Bob" == Bob Rossi <bob@brasko.net> writes:
> 
>  Bob> On Wed, Oct 06, 2004 at 02:26:55PM +0200, Eli Zaretskii wrote:
>  >> > Date: Wed, 6 Oct 2004 07:27:03 -0400 > From: Bob Rossi
>  >> <bob@brasko.net> > Cc: Daniel Jacobowitz <drow@false.org>,
>  >> gdb@sources.redhat.com
>  >> > 
>  >> > > First, it is possible that when the front end knows which MI
>  >> version > > is the last stable one, it will not need to restart
>  >> GDB, but just > > arrange for the appropriate parser to be used
>  >> for the rest of the > > session.
>  >> > 
>  >> > This is not correct. The front end has parsers for different
>  >> versions of > GDB's MI protocol. The parser for MI2 will not work
>  >> for the MI3 protocol
>  >> 
>  >> In general, it won't, but for a very specific case of
>  >> _a_single_command_, it could very well do.
> 
>  Bob> You obviously not understanding the point here. I can not even
>  Bob> get my front end to the point where it can look at the
>  Bob> command. The reason is, I can not *PARSE* the command.
> 
>  Bob> Here is a simple explanation that I have tried to discuss over
>  Bob> and over.
>    
>  Bob> 1. Each version of MI comes with a grammar.  2. If the MI
>  Bob> grammar changes between MI1 and MI2 then 3. A parser is
>  Bob> generated that understands the grammar for MI1 4. A parser is
>  Bob> generated that understands the grammar for MI2 5. The parser for
>  Bob> MI1 *will not parse* the output of MI2 6. The parser for MI2
>  Bob> *will not parse* the output of MI1
> 
> I'm puzzled.  If MI2 is a superset of MI1, then the parser for MI2 by
> definition will parse any string in MI1.  And generalizing, unless MI1
> and MI2 have essentially nothing in common, I don't see how it can be
> true that you cannot parse any command at all.
> 
> Just as in any protocol, you need version numbers to cope with the
> situation where a new MIx is NOT just a superset of MI<x-1>.  But the
> usual picture of protocol evolution is that those cases are not all
> that common -- most evoluation creates supersets.

Paul, you are almost correct, but you are not. The MIx is not a superset
of an MI<x-1>. They are incompatible. That is the problem.

Bob Rossi

Re: Bumping MI protocol

[Bob Rossi]

On Wed, Oct 06, 2004 at 09:57:27AM -0700, Felix Lee wrote:
> "Eli Zaretskii" <eliz@gnu.org>:
> > > From: Bob Rossi <bob@brasko.net>
> > > Exscuse me for being frank, your statements about this question are foolish.
> > 
> > I, for one, don't think Nathan's comments are foolish.  As a volunteer
> > project, we shouldn't waste too much time discussing hypothetical
> > issues.
> 
> I agree with Eli and Nathan, from a different angle.
> 
> I've never tried implementing a gdb front-end, but if I had to do
> one, I wouldn't rely on gdb conforming exactly to any particular
> specification, because bugs happen, and eliminating all bugs is
> not going to happen in my lifetime.

OK, so here it is again. GDB does not plan on supporting people that
generate there parser from the official MI output syntax ( grammar )?

> users are unlikely to be happy about restarting a complicated
> debugging session when they encounter a bug in the debugger, so a
> robust front-end will need to do some sanity checking of the
> conversation, and it will also need a method of resynchronizing
> the conversation when the sanity checks fail.

Yes, the grammar needs to change. This should all be taken into account
during the development of an MI protocol. Tests should be made for every
MI output command, and the output should be tested to make sure they
conform to the syntax.

> if a front-end has this basic adaptability, then it's not that
> big a deal if any one-off version of gdb doesn't conform exactly
> to spec.  so you can concentrate effort on making things work
> well for the versions of gdb that are commonly in use.
> --

Yes yes, you want to see me write one large parser that handles
everything and anything thrown at it, including the english language.

Bob Rossi

Re: probing GDB for MI versions

[Nathan J. Williams]

"'Bob Rossi'" <bob@brasko.net> writes:

> It is now a formal requirement of the GDB group

I am not a particular representative of GDB or its formal decisions. I
am mostly in the sidelines of GDB development, though I happen to have
some limited commit access. Please do not mistake my remarks, mostly
informed just by watching this list, as representing the official
decisions of some body to which I do not belong.

> The whole reason an MI grammar was invented was so that there were no
> "utterly minimal, unintelligent parser" nonsense going on in front ends.

Well, if you want to interrogate GDB for what versions it has
avaliable (as in your suggestion for a command line option), you have
to do that somewhere, and that will still take some parsing. Would it
make you happy if the mechanism for doing that was declared, formally,
not to be part of MI and its grammar, but just a suspiciously
similar-looking interactive command?

        - Nathan

Re: probing GDB for MI versions

[Alain Magloire]

> 
> On Wed, Oct 06, 2004 at 12:50:34PM +0100, Dave Korn wrote:
> > > -----Original Message-----
> > > From: gdb-owner On Behalf Of Bob Rossi
> > > Sent: 06 October 2004 12:39
> > 
> > > Unfortunately this topic is on two different threads. I feel 
> > > badly that I
> > > am wasting your time here with bad descriptions of the 
> > > "catch-22". This
> > > is to help make my opinion clear on why it is a "catch-22" and not
> > > possible.
> > > 
> > >    The front end has parsers for different versions of GDB's 
> > > MI protocol. 
> > >    The parser for MI2 may not work for the MI3 protocol.
> > >    The parser for the MI3 protocol may not work for the MI2 protocol.
> > >    The front end *can not* start up GDB just by using -interpreter=mi
> > >    because it doesn't know what parser to use in this situation.
> > >    Can we agree on this point for starters?
> > 
> >   No, we can't.  As long as the output from the -mi-version MI command stays
> > in the same format, you can always parse that and determine which version to
> > use.  
> 
> Dave, you do not understand the problem at all. I do not appreciate your
> defininative answer, especially since it is incorrect.
> 
> The actual MI output syntax is capable of changing between MI versions.
> If the MI4 output syntax (grammar) has an incompatible change with MI3,
> then 
>    * the MI3 parser will not even be capable of parsing and building a 
>      parse tree for the MI4 protocol.
>    * the MI4 parser will not even be capable of parsing and building a
>      parse tree for the MI3 protocol.
> 
> It is not possible to understand the output of the command no matter how
> simple it is. If there is no parse tree, then there is no way to
> understand the output from GDB.
> 
> > Everything else can change.  You can start up with an utterly minimal,
> > unintelligent parser, that knows nothing except how to send a -mi-version
> > command and parse the output; that parser can then direct one of your
> > version-dependent parsers to take over.
> 
> I don't understand the concept of an "utterly minimal unintelligent parser". 
> That is rediculous. I am generating a parser from the grammar.
> 
> There absolutly needs to be a way for the front end to ask GDB what
> versions of the MI protocol it supports. 
> 
> There is no way the front end can ask GDB what protocols it supports if
> it needs to talk to it with an MI protocol. Understood?
> 

I'm not sure on your rationnale to reject Dave's proposition.  It seems
to me it is a perfectly valid alternative for a front-end to probe
gdb and do an educated guess on what the better version of MI it 
can support.

gdb --interpreter=mi executable
(gdb) 1-mi-level
1^done,value="1"

The front-end loads MI Parser level 1 and continue exchange with gdb.

The other approach that was suggested, seems also interresting;
asking gdb on the command line for the list of protocols.
This first pass probing will allow the front-end to make a good choice
also.


The first idea to keep on probing gdb :

$ gdb -i mi5 executable
Interpreter `mi45' unrecognized
# try a nother
$ gdb -i mi4 executable
Interpreter `mi4' unrecognized
$ gdb -i mi2 executable
Bingo !!!

seems cumbersone but should work.

The problem that I did not see you mention in any previous thread, is
when there is a bug fix !! for example:
-thread-list-ids, keep on crashing, the next version of gdb fixes
the problem, how will a front-end knows to not use "info threads" but
can now use "-thread-list-ids".  Andrew's answer to this was to look
at the gdb version and make an educated guess, but we know the problem
with this, many distrubution have mangle gdb --version


(Just came back from a 2 weeks break, so I may have missed some context).

Re: probing GDB for MI versions

['Bob Rossi']

Sorry if I was rude here, I am very frustrated.

No one has attempted to do what I am trying to do. Write a front end
that is capable of working with different GDB's.

If they do do this, I would like to know how they negotiate the MI
version to talk.

Again, you seem to be saying that if I generate a parser off of the MI
output syntax, that I am somehow wrong.

Is this the general feel of the community?

Bob Rossi


On Wed, Oct 06, 2004 at 05:55:28PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: 'Bob Rossi'  
> > Sent: 06 October 2004 17:22
> 
> > On Wed, Oct 06, 2004 at 12:50:34PM +0100, Dave Korn wrote:
> > > > -----Original Message-----
> > > > From: gdb-owner On Behalf Of Bob Rossi
> > > > Sent: 06 October 2004 12:39
> 
> > > >    The front end has parsers for different versions of GDB's 
> > > > MI protocol. 
> > > >    The parser for MI2 may not work for the MI3 protocol.
> > > >    The parser for the MI3 protocol may not work for the 
> > MI2 protocol.
> > > >    The front end *can not* start up GDB just by using 
> > -interpreter=mi
> > > >    because it doesn't know what parser to use in this situation.
> > > >    Can we agree on this point for starters?
> > > 
> > >   No, we can't.  As long as the output from the -mi-version 
> > MI command stays
> > > in the same format, you can always parse that and determine 
> > which version to
> > > use.  
> 
> > Dave, you do not understand the problem at all. I do not 
> > appreciate your
> > defininative answer, especially since it is incorrect.
> 
> #1.  Well, I don't appreciate your rudeness, but hey, we don't always get
> what we want in life.  Guess you're just SOL.
> 
> #2.  My answer IS correct.  I DO understand the problem, and in fact I
> understand it better enough than you do that I can see the very very obvious
> solution (that you aren't capable of grasping) as well as the problem
> itself.
> 
> #3.  Why do you have to be the _only_ person in the entire software industry
> who isn't capable of dealing with elementary versioning and compatibility
> issues?  These techniques work fine for EVERYONE else but you.
> 
> > The actual MI output syntax is capable of changing between MI 
> > versions.
> 
>   Yes.  I hope we're all agreed that there is no hope of (nor point to)
> tracking a work-in-progress as it changes on a day-by-day basis.
> 
> > If the MI4 output syntax (grammar) has an incompatible change 
> > with MI3,
> > then 
> >    * the MI3 parser will not even be capable of parsing and 
> > building a 
> >      parse tree for the MI4 protocol.
> >    * the MI4 parser will not even be capable of parsing and building a
> >      parse tree for the MI3 protocol.
> 
>   Try and think outside the box.  Your over-reliance on tools is hobbling
> you.  You aren't obliged by statute to use an automatically generated parser
> based on a formal grammar.  You can use printf to send the -mi-version
> command to the gdb instance, and you can use sscanf to parse the version
> number out of the string "MI version is XXXX" that it returns.
> 
> > It is not possible to understand the output of the command no 
> > matter how simple it is. 
> 
>   Speak for yourself.  I can understand it, it's human readable.  I could
> write a very very very simple bit of code using sscanf that would understand
> it.  You might have a problem understanding it, but you're the only one who
> does, and there's no need for you to.
> 
> >If there is no parse tree, then there is no way to
> > understand the output from GDB.
> 
>   Don't be so facile.  You send one very simple command, get back one very
> simple output that you can parse with strcmp or sscanf, for crying out loud.
> Then you know what MI version you're dealing with.
> 
> > I don't understand the concept of an "utterly minimal 
> > unintelligent parser". 
> 
>   Well, you're clearly biting off more than you can chew with this entire
> project.  As I said above, something of the degree of complexity of a single
> sscanf statement is what I mean.
> 
> > That is rediculous. I am generating a parser from the grammar.
> >
> > There absolutly needs to be a way for the front end to ask GDB what
> > versions of the MI protocol it supports. 
> > 
> > There is no way the front end can ask GDB what protocols it 
> > supports if
> > it needs to talk to it with an MI protocol. Understood?
> 
>   I understand what you're claiming, but I gave you a perfectly clear and
> simple way of doing it.  You haven't demonstrated any problem with my
> proposal, because as you said above, you haven't even understood it yet.
> When you do understand it, you'll also understand that it works just fine.
> 
>     cheers, 
>       DaveK
> -- 
> Can't think of a witty .sigline today....

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> If at some point, GDB decides not to honor MI2 anymore, I need to make
> sure that I know that. If my front end only supports MI2, and GDB
> supports only MI3, than the function you are suggesting will not be good
> enough for me.

I think there's no chance that situation will occur.

if sometime in the future gdb stops honoring MI7, then presumably
it honors a newer version, MI21.  since your front-end knows
about MI21, then you don't care that MI7 is gone.  so that's not
a problem.

if MI7 is the only version that a front-end knows, then that's a
strong argument against removing MI7, so that's not a problem
either.
--

Re: probing GDB for MI versions

['Bob Rossi']

On Wed, Oct 06, 2004 at 01:03:14PM -0400, Nathan J. Williams wrote:
> "'Bob Rossi'" <bob@brasko.net> writes:
> 
> > It is now a formal requirement of the GDB group
> 
> I am not a particular representative of GDB or its formal decisions. I
> am mostly in the sidelines of GDB development, though I happen to have
> some limited commit access. Please do not mistake my remarks, mostly
> informed just by watching this list, as representing the official
> decisions of some body to which I do not belong.
> 
> > The whole reason an MI grammar was invented was so that there were no
> > "utterly minimal, unintelligent parser" nonsense going on in front ends.
> 
> Well, if you want to interrogate GDB for what versions it has
> avaliable (as in your suggestion for a command line option), you have
> to do that somewhere, and that will still take some parsing. Would it
> make you happy if the mechanism for doing that was declared, formally,
> not to be part of MI and its grammar, but just a suspiciously
> similar-looking interactive command?

Yes, that is a great idea! and it would make me even me happy!

GDB -i=list-protocols
mi1
mi2
mi3
annotate1
annotate2

There could be an interpreter that is only capable of outputting the
protocols of MI that it officially supports. We could document that it
will output one officially supported protocol on a line. This would make
me very happy. At the same time, we could output the annotate version
also.

Thanks,
Bob Rossi

RE: probing GDB for MI versions

[Dave Korn]

> -----Original Message-----
> From: 'Bob Rossi' 
> Sent: 06 October 2004 18:05

> Sorry if I was rude here, I am very frustrated.

  It shows.  But seriously, if you have to keep on saying the same thing
over and over again, we're not disagreeing with you just to be contrary,
it's because either _we_ haven't understood the problem, or because _you_
haven't understood the solutions we've proposed.  At that point, there's a
communication difficulty going on, which will not be resolved by simply
repeating the same description over and over getting more angry each time.

> No one has attempted to do what I am trying to do. Write a front end
> that is capable of working with different GDB's.
> 
> If they do do this, I would like to know how they negotiate the MI
> version to talk.
> 
> Again, you seem to be saying that if I generate a parser off of the MI
> output syntax, that I am somehow wrong.

  No, that's not what I'm saying.  I fully accept that you have to know what
version to deal with in order to invoke the correct full parser, and I fully
accept that while in general newer versions are supersets there are also
genuine backwards-incompatibilities that would require different parsing.
It's entirely proper to generate a parser from the MI output syntax.

  The only thing I'm disagreeing is your assumption that there's no way of
determining which MI version to talk without using a full MI parser.  You
can do it MUCH more simply than that.  That's the point which people keep on
having to repeat to you each time you repeat your description of the
problem, because while everyone understands the initial problem, nobody sees
what's wrong with the solutions that have been proposed so far.

> Is this the general feel of the community?

  Well, it's not what I feel, as I hope I've explained patiently above.  I
wouldn't care to speak for the community at large, but I would be surprised
if anyone else felt that it was wrong to generate a parser from the MI
output syntax.  What I feel is wrong is your assumption that a generated
parser is the only possible means of processing plain ascii human readable
text for the purpose of finding and extracting a single integer value.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: GDB/MI snapshots between major release's

[Daniel Jacobowitz]

On Wed, Oct 06, 2004 at 10:12:53AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > If at some point, GDB decides not to honor MI2 anymore, I need to make
> > sure that I know that. If my front end only supports MI2, and GDB
> > supports only MI3, than the function you are suggesting will not be good
> > enough for me.
> 
> I think there's no chance that situation will occur.
> 
> if sometime in the future gdb stops honoring MI7, then presumably
> it honors a newer version, MI21.  since your front-end knows
> about MI21, then you don't care that MI7 is gone.  so that's not
> a problem.
> 
> if MI7 is the only version that a front-end knows, then that's a
> strong argument against removing MI7, so that's not a problem
> either.

Actually, I doubt GDB will continue to support old MI versions
indefinitely.  It may be very hard.  For instance, at some point we may
report multiple events to the front end at once (from different
threads); or multiple addresses associated with a breakpoint.  Faking
an old interface will not be worth the trouble.

I expect there will be points at which front ends will have to be
updated to talk to a new GDB.

-- 
Daniel Jacobowitz

Re: probing GDB for MI versions

['Bob Rossi']

On Wed, Oct 06, 2004 at 06:14:49PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: 'Bob Rossi' 
> > Sent: 06 October 2004 18:05
> 
> > Sorry if I was rude here, I am very frustrated.
> 
>   It shows.  But seriously, if you have to keep on saying the same thing
> over and over again, we're not disagreeing with you just to be contrary,
> it's because either _we_ haven't understood the problem, or because _you_
> haven't understood the solutions we've proposed.  At that point, there's a
> communication difficulty going on, which will not be resolved by simply
> repeating the same description over and over getting more angry each time.

Understood.

> > No one has attempted to do what I am trying to do. Write a front end
> > that is capable of working with different GDB's.
> > 
> > If they do do this, I would like to know how they negotiate the MI
> > version to talk.
> > 
> > Again, you seem to be saying that if I generate a parser off of the MI
> > output syntax, that I am somehow wrong.
> 
>   No, that's not what I'm saying.  I fully accept that you have to know what
> version to deal with in order to invoke the correct full parser, and I fully
> accept that while in general newer versions are supersets there are also
> genuine backwards-incompatibilities that would require different parsing.
> It's entirely proper to generate a parser from the MI output syntax.
> 
>   The only thing I'm disagreeing is your assumption that there's no way of
> determining which MI version to talk without using a full MI parser.  You
> can do it MUCH more simply than that.  That's the point which people keep on
> having to repeat to you each time you repeat your description of the
> problem, because while everyone understands the initial problem, nobody sees
> what's wrong with the solutions that have been proposed so far.

You are the first person so far that has pointed out directly to me that
you understand the problem I am describing.

> > Is this the general feel of the community?
> 
>   Well, it's not what I feel, as I hope I've explained patiently above.  I
> wouldn't care to speak for the community at large, but I would be surprised
> if anyone else felt that it was wrong to generate a parser from the MI
> output syntax.  What I feel is wrong is your assumption that a generated
> parser is the only possible means of processing plain ascii human readable
> text for the purpose of finding and extracting a single integer value.

I guess the bottom line is, I already have a parser that is capable of
dealing with a specific version of MI's output. I don't want to start up
MI with an adhoc parser, just to figure out what real parser I should
use. This seems not correct to me, and I guess it's the issue to deal
with. 

The problem is, we would be adding a command to the MI function set that
would not be able to be parsed and understood with an MI parser. This
seems really wrong to me. It's probably the issue we should be
discussing.

Thanks,
Bob Rossi

Re: probing GDB for MI versions

[Daniel Jacobowitz]

On Wed, Oct 06, 2004 at 01:21:38PM -0400, 'Bob Rossi' wrote:
> I guess the bottom line is, I already have a parser that is capable of
> dealing with a specific version of MI's output. I don't want to start up
> MI with an adhoc parser, just to figure out what real parser I should
> use. This seems not correct to me, and I guess it's the issue to deal
> with. 

You've got a hammer and are attempting to create a nail.  It seems
eminently correct to me, and to Dave too I think.

-- 
Daniel Jacobowitz

RE: probing GDB for MI versions

[Dave Korn]

> -----Original Message-----
> From: 'Bob Rossi' 
> Sent: 06 October 2004 18:22

> I guess the bottom line is, I already have a parser that is capable of
> dealing with a specific version of MI's output. I don't want 
> to start up
> MI with an adhoc parser, just to figure out what real parser I should
> use. This seems not correct to me, and I guess it's the issue to deal
> with. 


  It's absolutely correct.  You have the tools for the job, but you need a
piece of information in order to select the correct tool.  Since you cannot
use the tool to get the information to select the tool to .......... as you
so correctly point out, the answer is to use a _different_ tool.  And a
crude ad-hoc parser is just the tool for the job.

> The problem is, we would be adding a command to the MI 
> function set that
> would not be able to be parsed and understood with an MI parser. This
> seems really wrong to me. It's probably the issue we should be
> discussing.

  There's no reason why your version-specific MI parsers shouldn't both be
able to understand the output from the -mi-version command as well.  But you
will need the ad-hoc one to get started with.  If you don't like the idea of
an ad-hoc parser, you could always call it a "recognizer" instead...... 

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: probing GDB for MI versions

[Bob Rossi]

On Wed, Oct 06, 2004 at 01:24:03PM -0400, Daniel Jacobowitz wrote:
> On Wed, Oct 06, 2004 at 01:21:38PM -0400, 'Bob Rossi' wrote:
> > I guess the bottom line is, I already have a parser that is capable of
> > dealing with a specific version of MI's output. I don't want to start up
> > MI with an adhoc parser, just to figure out what real parser I should
> > use. This seems not correct to me, and I guess it's the issue to deal
> > with. 
> 
> You've got a hammer and are attempting to create a nail.  It seems
> eminently correct to me, and to Dave too I think.

Unfortunately, I don't understand what this means. Could you please
explain?

I want to make one thing clear, Eli's suggesting of making an MI command
that returns the supported MI versions has one problem. We are adding a 
command to an MI protocol that can not be understood by a program that 
can speak a protocol. The program must,

   1. Have a parser that understands the protocol it wants to speak
   (obvious and easy to get)
   2. Have a parser that understands all future non invented protocols
   of the MI output syntax, and will be capable of parsing the current
   and future protocols to get the information it needs.
   (mostly not possible)

Will someone explain to me how they expect to write a parser capable of
getting some information out of MI2, but prove to me that it will work
with MI100.

Thanks,
Bob Rossi

RE: probing GDB for MI versions

[Dave Korn]

> -----Original Message-----
> From: Bob Rossi [mailto:bob@brasko.net] 


> I want to make one thing clear, Eli's suggesting of making an 
> MI command
> that returns the supported MI versions has one problem. We 
> are adding a 
> command to an MI protocol that can not be understood by a 
> program that 
> can speak a protocol. The program must,
> 
>    1. Have a parser that understands the protocol it wants to speak
>    (obvious and easy to get)
>    2. Have a parser that understands all future non invented protocols
>    of the MI output syntax, and will be capable of parsing the current
>    and future protocols to get the information it needs.
>    (mostly not possible)

  False inference.

> Will someone explain to me how they expect to write a parser 
> capable of
> getting some information out of MI2, but prove to me that it will work
> with MI100.

  Simple.

  Any time anyone proposes changing the output format of the -mi-version
command, or removing it, we'll just say no.  Fr'ex:

  The -mi-version command will ALWAYS AND FOREVER output a string of the
format

"Highest supported MI version is XXXX"

where XXXX is an ASCII decimal integer.  Any program can then read the
output from an invocation of gdb and simply discard everything up until it
finds that string, then parse the integer out.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: probing GDB for MI versions

[Paul Koning]

>>>>> "Bob" == Bob Rossi <Bob> writes:

 >> > Is this the general feel of the community?
 >> 
 >> Well, it's not what I feel, as I hope I've explained patiently
 >> above.  I wouldn't care to speak for the community at large, but I
 >> would be surprised if anyone else felt that it was wrong to
 >> generate a parser from the MI output syntax.  What I feel is wrong
 >> is your assumption that a generated parser is the only possible
 >> means of processing plain ascii human readable text for the
 >> purpose of finding and extracting a single integer value.

 Bob> I guess the bottom line is, I already have a parser that is
 Bob> capable of dealing with a specific version of MI's output. I
 Bob> don't want to start up MI with an adhoc parser, just to figure
 Bob> out what real parser I should use. This seems not correct to me,
 Bob> and I guess it's the issue to deal with.

Bob, that actually IS correct and the conventional way to handle
things.  In typical protocol design, the conversation starts with a
message that carries version information.  The protocol state machine
initially comes up in a state where it expects that message and knows
how to find the version information.  Once it knows that, it flips to
the state machine for that version.

Note that the "ad hoc" part typically only involves one or two
messages and often only a small part of the content of those
messages.  For example, the initial message might be a "create
connection" message, carrying dozens of fields one of which is a
version number.  The first step is to find that version number; after
that is known, all the rest including the full parse of that initial
message can be done by the full parse machinery.

(Alternatively, there might be a combined state machine -- in your
notation, that would be a grammar for the union of MI1 and MI2, with
condition checking on the version number to forbid certain production
rules.  That may work for some protocols; I doubt it's a sensible
answer for MI.)

       paul

Re: probing GDB for MI versions

['Bob Rossi']

On Wed, Oct 06, 2004 at 06:41:05PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: Bob Rossi [mailto:bob@brasko.net] 
> 
> 
> > I want to make one thing clear, Eli's suggesting of making an 
> > MI command
> > that returns the supported MI versions has one problem. We 
> > are adding a 
> > command to an MI protocol that can not be understood by a 
> > program that 
> > can speak a protocol. The program must,
> > 
> >    1. Have a parser that understands the protocol it wants to speak
> >    (obvious and easy to get)
> >    2. Have a parser that understands all future non invented protocols
> >    of the MI output syntax, and will be capable of parsing the current
> >    and future protocols to get the information it needs.
> >    (mostly not possible)
> 
>   False inference.

I don't believe it's false yet.

> > Will someone explain to me how they expect to write a parser 
> > capable of
> > getting some information out of MI2, but prove to me that it will work
> > with MI100.
> 
>   Simple.
> 
>   Any time anyone proposes changing the output format of the -mi-version
> command, or removing it, we'll just say no.  Fr'ex:
> 
>   The -mi-version command will ALWAYS AND FOREVER output a string of the
> format
> 
> "Highest supported MI version is XXXX"
> 
> where XXXX is an ASCII decimal integer.  Any program can then read the
> output from an invocation of gdb and simply discard everything up until it
> finds that string, then parse the integer out.

Unfortunatly you are only thinking of the output of the MI command. Not
the actual syntax of the MI output. This could change and you have to
deal with it.

So, to restate,

2. Have a parser that understands all future non invented protocols
   of the MI output syntax, and will be capable of parsing the current
   and future protocols to get the information it needs.
   (mostly not possible)

Dave, can you write a piece of code that can take all of the output of
GDB, from when it starts until after it exists (only given this new MI
command), and return to me the currently supported interfaces?

Will this code work with MI5, MI6 and MI7. Since it is likely that there
will be syntax changes?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Daniel Jacobowitz <drow@false.org>:
> Actually, I doubt GDB will continue to support old MI versions
> indefinitely.  It may be very hard.  For instance, at some point we may
> report multiple events to the front end at once (from different
> threads); or multiple addresses associated with a breakpoint.  Faking
> an old interface will not be worth the trouble.

> I expect there will be points at which front ends will have to be
> updated to talk to a new GDB.

right.  if it's too hard to support an old MI, any front-end
using the old MI will have the wrong model of interaction with
gdb, so the front-end will need substantial work to talk to the
new gdb no matter what, so that's not a problem either.
--

Re: probing GDB for MI versions

[Bob Rossi]

On Wed, Oct 06, 2004 at 01:47:57PM -0400, Paul Koning wrote:
> >>>>> "Bob" == Bob Rossi <Bob> writes:
> 
>  >> > Is this the general feel of the community?
>  >> 
>  >> Well, it's not what I feel, as I hope I've explained patiently
>  >> above.  I wouldn't care to speak for the community at large, but I
>  >> would be surprised if anyone else felt that it was wrong to
>  >> generate a parser from the MI output syntax.  What I feel is wrong
>  >> is your assumption that a generated parser is the only possible
>  >> means of processing plain ascii human readable text for the
>  >> purpose of finding and extracting a single integer value.
> 
>  Bob> I guess the bottom line is, I already have a parser that is
>  Bob> capable of dealing with a specific version of MI's output. I
>  Bob> don't want to start up MI with an adhoc parser, just to figure
>  Bob> out what real parser I should use. This seems not correct to me,
>  Bob> and I guess it's the issue to deal with.
> 
> Bob, that actually IS correct and the conventional way to handle
> things.  In typical protocol design, the conversation starts with a
> message that carries version information.  The protocol state machine
> initially comes up in a state where it expects that message and knows
> how to find the version information.  Once it knows that, it flips to
> the state machine for that version.
> 
> Note that the "ad hoc" part typically only involves one or two
> messages and often only a small part of the content of those
> messages.  For example, the initial message might be a "create
> connection" message, carrying dozens of fields one of which is a
> version number.  The first step is to find that version number; after
> that is known, all the rest including the full parse of that initial
> message can be done by the full parse machinery.

Yes, you are correct. I understand this. I think the problem is 2 fold.
It is confusing and (IMO) incorrect to add a command to the MI function
set that can not be used for the purposes that it needs to be by a program 
that speaks the MI protocol. I new parser needs to be written that does
not conform to the MI protocol.

MI is an evolving protocol, and it would be useful to just have either a
command line swith, which could send info in a trivial line based
manner, or have a new interpreter, that only says what other
interpreters that the current GDB supports.

These are simple solutions that would not involve much from the front
end developer and would result in code that could be written probably to
a format that will not change.

Thanks,
Bob Rosi

Re: probing GDB for MI versions

[Paul Koning]

>>>>> "Bob" == Bob Rossi <Bob> writes:

 Bob> On Wed, Oct 06, 2004 at 06:41:05PM +0100, Dave Korn wrote:
 >> > -----Original Message----- > From: Bob Rossi

 >> > Will someone explain to me how they expect to write a parser >
 >> capable of > getting some information out of MI2, but prove to me
 >> that it will work > with MI100.
 >> 
 >> Simple.
 >> 
 >> Any time anyone proposes changing the output format of the
 >> -mi-version command, or removing it, we'll just say no.  Fr'ex:
 >> 
 >> The -mi-version command will ALWAYS AND FOREVER output a string of
 >> the format
 >> 
 >> "Highest supported MI version is XXXX"
 >> 
 >> where XXXX is an ASCII decimal integer.  Any program can then read
 >> the output from an invocation of gdb and simply discard everything
 >> up until it finds that string, then parse the integer out.

 Bob> Unfortunatly you are only thinking of the output of the MI
 Bob> command. Not the actual syntax of the MI output. This could
 Bob> change and you have to deal with it.

No, Dave is right.  This is how protocol version handling is done in
protocol design practice.

The key point is this:

a. There is a well-defined way to convey the protocol version 
   information early on in the exchange.  It may come as part of the
   startup message -- if there is such a thing.  Or it may be
   a reply to a query that is allowed in the initial state.

b. The following items are immutable across versions:
   1. The subset of parsing rules you need to find the version 
      data.  That need not be a full parse; for example, it can
      be something as simple as "the first 5 bytes of the first
      message you receive".  Or it might be "tag 42 of the
      tag/length/value encoded payload of the first message is
      the version number".
   2. The query that gets you the message -- if a query is used.

So the MI evolution is constrained only enough that such a version
mechanism can be defined, and no more than that.

	  paul

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> You obviously not understanding the point here. I can not even get my
> front end to the point where it can look at the command. The reason is,
> I can not *PARSE* the command. 

mostly, I don't understand why you feel you need to parse a
command before understanding it, when the command is something
simple like a 'who are you?' challenge/response.  most programs
that can speak to different clients will do some dynamic
adaptation of protocol based on interaction with the client.
it's not clear to me why you want to do it differently.

> Therefor, I don't have a parse tree, and can not even begin to
> understand what MI output command GDB just sent to me.

this seems to be the miscommunication going on.  I don't think I
need a parse tree to begin understanding output, and it's not
clear to me what programming model you're using that makes it
hard to do simple output recognition without a parse tree.
--

Re: probing GDB for MI versions

[Andrew Cagney]

>>> Will someone explain to me how they expect to write a parser 
>>> capable of
>>> getting some information out of MI2, but prove to me that it will work
>>> with MI100.
> 
> 
>   Simple.
> 
>   Any time anyone proposes changing the output format of the -mi-version
> command, or removing it, we'll just say no.  Fr'ex:
> 
>   The -mi-version command will ALWAYS AND FOREVER output a string of the
> format
> 
> "Highest supported MI version is XXXX"

anything like that.

> where XXXX is an ASCII decimal integer.  Any program can then read the
> output from an invocation of gdb and simply discard everything up until it
> finds that string, then parse the integer out.

Right, and tested (as always) using the testsuite.

I find this focus on such pedantic details both puzzling and time 
wasting.   Especially given that any code intended to handle multiple MI 
variants must be adhoc.  Otherwize it won't work with all the variants 
that pre-date the above - mi0, mi1, mi2 (prior to the above extension.

MI needs is additional commands and extensions, driven by the needs of 
Free software projects.  Neither of those - EMACS and Eclipse - appear 
to be having problems this technical nits such as this.

Andrew

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Wed, Oct 06, 2004 at 11:30:20AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > You obviously not understanding the point here. I can not even get my
> > front end to the point where it can look at the command. The reason is,
> > I can not *PARSE* the command. 
> 
> mostly, I don't understand why you feel you need to parse a
> command before understanding it, when the command is something
> simple like a 'who are you?' challenge/response.  most programs
> that can speak to different clients will do some dynamic
> adaptation of protocol based on interaction with the client.
> it's not clear to me why you want to do it differently.
> 
> > Therefor, I don't have a parse tree, and can not even begin to
> > understand what MI output command GDB just sent to me.
> 
> this seems to be the miscommunication going on.  I don't think I
> need a parse tree to begin understanding output, and it's not
> clear to me what programming model you're using that makes it
> hard to do simple output recognition without a parse tree.
> --

It's simply incorrect in my view to add the command to the MI command
set if no one expects you to use MI to use it. This is wierd.

I want to be able to use my MI parser's to read the MI protocol.

Bob Rossi

Re: probing GDB for MI versions

['Bob Rossi']

On Wed, Oct 06, 2004 at 02:41:09PM -0400, Andrew Cagney wrote:
> 
> >>>Will someone explain to me how they expect to write a parser 
> >>>capable of
> >>>getting some information out of MI2, but prove to me that it will work
> >>>with MI100.
> >
> >
> >  Simple.
> >
> >  Any time anyone proposes changing the output format of the -mi-version
> >command, or removing it, we'll just say no.  Fr'ex:
> >
> >  The -mi-version command will ALWAYS AND FOREVER output a string of the
> >format
> >
> >"Highest supported MI version is XXXX"
> 
> anything like that.
> 
> >where XXXX is an ASCII decimal integer.  Any program can then read the
> >output from an invocation of gdb and simply discard everything up until it
> >finds that string, then parse the integer out.
> 
> Right, and tested (as always) using the testsuite.
> 
> I find this focus on such pedantic details both puzzling and time 
> wasting.   Especially given that any code intended to handle multiple MI 
> variants must be adhoc.  Otherwize it won't work with all the variants 
> that pre-date the above - mi0, mi1, mi2 (prior to the above extension.

You are stating that a parser that implements an MIn Output syntax has
to be adhoc? I plan on having a parser for each of these interface's and
none of them is adhoc. I don't think you should force your adhoc
approach onto the front end developers.

> MI needs is additional commands and extensions, driven by the needs of 
> Free software projects.  Neither of those - EMACS and Eclipse - appear 
> to be having problems this technical nits such as this.

I can't explain why. 

Bob Rossi

Re: Bumping MI protocol

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> Yes yes, you want to see me write one large parser that handles
> everything and anything thrown at it, including the english language.

no, of course not, that's silly.  I keep trying to figure out why
we keep talking past each other.  at the moment, my best guess is
you're assuming that "MI version changes" is something that you
have no control over, while I'm assuming that you can easily have
a direct influence on "MI version changes".  I think the latter
is more true than the former.  have you worked with other free
software projects before?
--

Re: probing GDB for MI versions

[Andrew Cagney]

If a current GDB were modified to list mi "versions" then it would only 
print mi2, which is the version selected by -i=mi.  If your front end 
specifies -i=mi1 then you're on your own - it's not tested - it doesn't 
work.

Andrew

Re: probing GDB for MI versions

[Andrew Cagney]

>>> I find this focus on such pedantic details both puzzling and time 
>>> wasting.   Especially given that any code intended to handle multiple MI 
>>> variants must be adhoc.  Otherwize it won't work with all the variants 
>>> that pre-date the above - mi0, mi1, mi2 (prior to the above extension.

s/handle multiple/handle initial negotiation of multiple/

As everyone else has pointed out, with the negitiation done, the real 
parser can be loaded.

> You are stating that a parser that implements an MIn Output syntax has
> to be adhoc? I plan on having a parser for each of these interface's and
> none of them is adhoc. I don't think you should force your adhoc
> approach onto the front end developers.
> 
> 
>>> MI needs is additional commands and extensions, driven by the needs of 
>>> Free software projects.  Neither of those - EMACS and Eclipse - appear 
>>> to be having problems this technical nits such as this.
> 
> 
> I can't explain why. 

Andrew

Re: probing GDB for MI versions

[Bob Rossi]

On Wed, Oct 06, 2004 at 03:09:58PM -0400, Andrew Cagney wrote:
> If a current GDB were modified to list mi "versions" then it would only 
> print mi2, which is the version selected by -i=mi.  If your front end 
> specifies -i=mi1 then you're on your own - it's not tested - it doesn't 
> work.

WHAT?!? This is what I have been asking all along? It was the foundation
to this conversation. Where were you to inform everyone of this? 

Are you saying that old versions of MI are not supported by GDB? Only
the last official release of the MI protocol is supported and that no
other versions that it used to speak with are supported or tested?

Thanks,
Bob Rossi

Re: probing GDB for MI versions

['Bob Rossi']

On Wed, Oct 06, 2004 at 03:16:20PM -0400, Andrew Cagney wrote:
> 
> >>>I find this focus on such pedantic details both puzzling and time 
> >>>wasting.   Especially given that any code intended to handle multiple MI 
> >>>variants must be adhoc.  Otherwize it won't work with all the variants 
> >>>that pre-date the above - mi0, mi1, mi2 (prior to the above extension.
> 
> s/handle multiple/handle initial negotiation of multiple/
> 
> As everyone else has pointed out, with the negitiation done, the real 
> parser can be loaded.

Yes, this is obvious and it's not the problem.

Bob Rossi

Re: Bumping MI protocol

[Bob Rossi]

On Wed, Oct 06, 2004 at 11:54:07AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > Yes yes, you want to see me write one large parser that handles
> > everything and anything thrown at it, including the english language.
> 
> no, of course not, that's silly.  I keep trying to figure out why
> we keep talking past each other.  at the moment, my best guess is
> you're assuming that "MI version changes" is something that you
> have no control over, while I'm assuming that you can easily have
> a direct influence on "MI version changes".  I think the latter
> is more true than the former.  have you worked with other free
> software projects before?

No, I have not. GDB is the first project I am working with. I find the
MI protocol exciting in the sense that a good front end can finally be
written. However, I have a good amount of experience with parsers and
proprietary software.

I am assuming that the MI output syntax will change. I expect it to. We
will need things in the future we do not know we need yet.

My real problem is adding an MI command to the MI function set that
can not be used by an MI parser. I very much dislike writing ad hoc
parsers. If the problem can be solved another way, I would be much
happier. If it can't, I will have to live with what is here.

Bob Rossi

Re: Bumping MI protocol

[Bob Rossi]

On Wed, Oct 06, 2004 at 12:41:10PM -0400, Nathan J. Williams wrote:
> Bob Rossi <bob@brasko.net> writes:
> 
> > Either one of you, please describe to me which of these questions is
> > foolish, and I will clearly explain to you why I need to know this
> > information in order to build a front end.
> 
> That you need to know this information, or think you need to know this
> information, does not imply that it exists. I'm suggesting that MI is
> young and unevolved enough that there is no serious body of work in
> woking with its evolution. This means that your questions of "What
> happens in case X?" are effectively "please spend time deciding what
> happens in case X, which has not yet occurred." To put it in other
> terms, an unfunded mandate.
> 
> I think you'll make much more ground by assuming that none of these
> questions have answers, and proposing possible answers (the "can you
> use an MI command to check the MI version" thread seems more
> productive to me, for example, because it included suggestions whose
> merits can be concretely dissussed).
> 
> > I am asking because it's not documented anywhere. If
> > you want the questions to stop, maybe you will see that there is not
> > enough information avaiable for front end developers to figure these
> > thngs out.
> 
> Yes, I think such things are not documented because they have not been
> considered or they have not come up to be handled, not because of a
> conspiracy to keep front-end developers in the dark.

Thanks, I understand your point of view here. I'll try to refrain from
"what if" questions. However, if I feel they will effect the implementation 
of my front end, I'll speak up.

Bob Rossi

Re: probing GDB for MI versions

[Alain Magloire]

> 
> On Wed, Oct 06, 2004 at 03:09:58PM -0400, Andrew Cagney wrote:
> > If a current GDB were modified to list mi "versions" then it would only 
> > print mi2, which is the version selected by -i=mi.  If your front end 
> > specifies -i=mi1 then you're on your own - it's not tested - it doesn't 
> > work.
> 
> WHAT?!? This is what I have been asking all along? It was the foundation
> to this conversation. Where were you to inform everyone of this? 
> 

But I think that was the folks been saying.  If you choose a specific
version to start gdb in your front-end say, "-i=mi1" why do you care
later to know about "mi2" or "mix" ?

If you start with "-i=mi", it will be handy to know which mi level,
in this case the front-end can take appropriate action
or restart trying a known version "-i=mi1" 

Am I missing something here ?
I'm curious to understand why you reject the others propositions as inadequate.

> Are you saying that old versions of MI are not supported by GDB? Only
> the last official release of the MI protocol is supported and that no
> other versions that it used to speak with are supported or tested?
> 

how did you manage to come up with such conclusions ? 

--
alain

Re: probing GDB for MI versions

[Andrew Cagney]

> On Wed, Oct 06, 2004 at 03:09:58PM -0400, Andrew Cagney wrote:
> 
>>> If a current GDB were modified to list mi "versions" then it would only 
>>> print mi2, which is the version selected by -i=mi.  If your front end 
>>> specifies -i=mi1 then you're on your own - it's not tested - it doesn't 
>>> work.
> 
> 
> WHAT?!? This is what I have been asking all along? It was the foundation
> to this conversation. Where were you to inform everyone of this? 

s/everyone/you/.  I've been reading the thread.

> Are you saying that old versions of MI are not supported by GDB? Only
> the last official release of the MI protocol is supported and that no
> other versions that it used to speak with are supported or tested?

I'm simply pointing out the obvious - what we don't test [likely] 
doesn't work.  I certainly wouldn't be putting the sheep station(1) on 
this one, given such odds.

Andrew

(1) Farm

Re: probing GDB for MI versions

[Bob Rossi]

On Wed, Oct 06, 2004 at 03:53:41PM -0400, Alain Magloire wrote:
> > 
> > On Wed, Oct 06, 2004 at 03:09:58PM -0400, Andrew Cagney wrote:
> > > If a current GDB were modified to list mi "versions" then it would only 
> > > print mi2, which is the version selected by -i=mi.  If your front end 
> > > specifies -i=mi1 then you're on your own - it's not tested - it doesn't 
> > > work.
> > 
> > WHAT?!? This is what I have been asking all along? It was the foundation
> > to this conversation. Where were you to inform everyone of this? 
> > 
> 
> But I think that was the folks been saying.  If you choose a specific
> version to start gdb in your front-end say, "-i=mi1" why do you care
> later to know about "mi2" or "mix" ?
> 
> If you start with "-i=mi", it will be handy to know which mi level,
> in this case the front-end can take appropriate action
> or restart trying a known version "-i=mi1" 
> 
> Am I missing something here ?
> I'm curious to understand why you reject the others propositions as inadequate.

Alain, I started some talks several days ago about how GDB behaves when
it comes to backwards compatibility of the MI protocols. Everyone has
told me that it supports the current official release, and it supports
all of the old releases.

As far as I can tell, several days later, andrew comes on the seen and
says that GDB only plans on supporting the last official release. This
is information I would to have like to had several days ago. Better yet,
it's information that should be documented for all to easily find the
answer to.

> > Are you saying that old versions of MI are not supported by GDB? Only
> > the last official release of the MI protocol is supported and that no
> > other versions that it used to speak with are supported or tested?
> > 
> 
> how did you manage to come up with such conclusions ? 

I am assuming this front what Andrew said below,

> > > If a current GDB were modified to list mi "versions" then it would only 
> > > print mi2, which is the version selected by -i=mi.  If your front end 
> > > specifies -i=mi1 then you're on your own - it's not tested - it doesn't 
> > > work.

Bobby

Re: Bumping MI protocol

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I am assuming that the MI output syntax will change. I expect it to. We
> will need things in the future we do not know we need yet.

sure.  and when that time comes you can help decide whether to
make the change in a way that's compatible with existing
front-ends, or bump the version to indicate an incompatibility.
if it's a nontrivial incompatibility, you can argue for calling
it something other than MI, to avoid confusing a front-end that
assumes all versions of MI have basically the same flavor.  or
you can argue for whatever seems best for the world at the time
of that hypothetical future.

there's not much point in spending a lot of effort guarding
against unlikely futures when you have a lot of influence over
the future.  the only thing unmovable is the past, and that's
already well-defined because the source code to every past
version of gdb is freely available.
--

RE: probing GDB for MI versions

[Dave Korn]

> -----Original Message-----
> From: 'Bob Rossi' [mailto:bob@brasko.net] 
> Sent: 06 October 2004 18:51

> Dave, can you write a piece of code that can take all of the output of
> GDB, from when it starts until after it exists (only given this new MI
> command), and return to me the currently supported interfaces?

  Yes, I can, but I'm not going to do it for you.  Here's a hint, in shell
terms:

echo "-mi-version" | gdb | grep "Highest supported MI version is" | ....

[you have to fill in the ... with some kind of sed or awk command]

> Will this code work with MI5, MI6 and MI7. Since it is likely 
> that there will be syntax changes?

  As long as the body text of that string that you blindly search for
remains the same, yes it will.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: probing GDB for MI versions

['Bob Rossi']

On Thu, Oct 07, 2004 at 10:04:29AM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: 'Bob Rossi' [mailto:bob@brasko.net] 
> > Sent: 06 October 2004 18:51
> 
> > Dave, can you write a piece of code that can take all of the output of
> > GDB, from when it starts until after it exists (only given this new MI
> > command), and return to me the currently supported interfaces?
> 
>   Yes, I can, but I'm not going to do it for you.  Here's a hint, in shell
> terms:
> 
> echo "-mi-version" | gdb | grep "Highest supported MI version is" | ....
> 
> [you have to fill in the ... with some kind of sed or awk command]
> 
> > Will this code work with MI5, MI6 and MI7. Since it is likely 
> > that there will be syntax changes?
> 
>   As long as the body text of that string that you blindly search for
> remains the same, yes it will.

OK, I agree with this. Why would we add this functionality as an MI command 
if the front ends all have to write some adhoc parser to get the
information?

So, I agree that it can be done, I just think it's a terrible idea.
We can do it in a much better way.

Bob Rossi

RE: probing GDB for MI versions

[Dave Korn]

> -----Original Message-----
> From: 'Bob Rossi' 
> Sent: 07 October 2004 13:36

> >   Yes, I can, but I'm not going to do it for you.  Here's a 
> hint, in shell
> > terms:
> > 
> > echo "-mi-version" | gdb | grep "Highest supported MI 
> version is" | ....
> > 
> > [you have to fill in the ... with some kind of sed or awk command]

> OK, I agree with this. Why would we add this functionality as 
> an MI command 
> if the front ends all have to write some adhoc parser to get the
> information?

  You use the term "adhoc parser" as if that were a bad thing.  It's not.
It's an entirely reasonable way for a computer program to parse some data
and extract some simple information that it requires.

> So, I agree that it can be done, I just think it's a terrible idea.
> We can do it in a much better way.

  This is an invalid argument.  You'll have to have *some* kind of 'parsing'
going on in order to interpret the output from gdb that lists the versions
of MI, no matter whether it's an MI command or a command-line option or
anything else.  So why you think one of those ways is terrible and the other
is not, on the basis of this requirement, which is in fact the same in both
cases anyway, I just don't see.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: probing GDB for MI versions

['Bob Rossi']

On Thu, Oct 07, 2004 at 01:48:04PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: 'Bob Rossi' 
> > Sent: 07 October 2004 13:36
> 
> > >   Yes, I can, but I'm not going to do it for you.  Here's a 
> > hint, in shell
> > > terms:
> > > 
> > > echo "-mi-version" | gdb | grep "Highest supported MI 
> > version is" | ....
> > > 
> > > [you have to fill in the ... with some kind of sed or awk command]
> 
> > OK, I agree with this. Why would we add this functionality as 
> > an MI command 
> > if the front ends all have to write some adhoc parser to get the
> > information?
> 
>   You use the term "adhoc parser" as if that were a bad thing.  It's not.
> It's an entirely reasonable way for a computer program to parse some data
> and extract some simple information that it requires.

You seem like you want "more of the old". GDB has come a long way from
the adhoc parsers the front end's had to generate to deal with the CLI.

The MI developers, wise as they are, decided to formalize the way GDB
output's data and front end developers parse it.

> > So, I agree that it can be done, I just think it's a terrible idea.
> > We can do it in a much better way.
> 
>   This is an invalid argument.  You'll have to have *some* kind of 'parsing'
> going on in order to interpret the output from gdb that lists the versions
> of MI, no matter whether it's an MI command or a command-line option or
> anything else.  So why you think one of those ways is terrible and the other
> is not, on the basis of this requirement, which is in fact the same in both
> cases anyway, I just don't see.

Getting the data, one line at a time, not in the context of an MI Output
command is fine with me. It has nothing to do with MI and I like that.

I have thought about this long enough to have come to a conclusion. I
think it is silly to add an MI command to GDB that can not be used by a
front end that speaks the MI protocol. 

   * Let's make this clear, MI commands are there for front ends that 
     speak the MI protocol.

The solution of adding an MI command that can only be looked at by an adhoc
parser and making rules like "the command will never change" is non-intuitive 
and confusing. Having a simple mechanism, such as a command line switch or a
new interpreter, would be simple and understandable.

Thanks,
Bob Rossi

RE: probing GDB for MI versions

[Dave Korn]

> -----Original Message-----
> From: 'Bob Rossi' 
> Sent: 07 October 2004 15:05

[Eli, if you'd rather I Cc you out of this
now-getting-fairly-pointless-and-repetitive discussion, just drop me a note
offlist]

> >   You use the term "adhoc parser" as if that were a bad 
> thing.  It's not.
> > It's an entirely reasonable way for a computer program to 
> parse some data
> > and extract some simple information that it requires.
> 
> You seem like you want "more of the old". 

  Don't put words in my mouth or impute motives to me, you know nothing
about me.

> GDB has come a long way from
> the adhoc parsers the front end's had to generate to deal 
> with the CLI.

  Your argument is a strawman.

> The MI developers, wise as they are, decided to formalize the way GDB
> output's data and front end developers parse it.

  Your insistence on using formal parsers for every single job regardless of
the fact that you can also see that they're not suitable for the job flies
in the face of sanity.  You're a child with a hammer and every single
problem looks to you like a nail.

> Getting the data, one line at a time, not in the context of 
> an MI Output
> command is fine with me. It has nothing to do with MI and I like that.

  Your rigidity and inflexibility of thought cripples your ability to apply
the appropriate tool to solve a VERY VERY SIMPLE problem.  It doesn't matter
if the data is in MI format, the simple string matching approach WILL STILL
FIND IT EMBEDDED IN THE MI FORMATTING.

> I have thought about this long enough to have come to a conclusion. I
> think it is silly to add an MI command to GDB that can not be 
> used by a front end that speaks the MI protocol. 

  Your claim is utterly false: of course the command can be used by such a
front end.  The front end can use whatever means it likes to select the
correct parser for the mi version of the gdb its using, and then the output
from the -mi-versions command can be parsed by it.  Just because I presented
the output as a simple plaintext string doesn't mean it shouldn't be given
in MI format, and I didn't say anything to suggest it should be, so this is
yet another strawman where you invent your own false representation of what
I've described and then attack the flaws you placed in your own invention.

>    * Let's make this clear, MI commands are there for front ends that 
>      speak the MI protocol.

  An irrelevant truism.

> The solution of adding an MI command that can only be looked 
> at by an adhoc parser 

  As I explain above, it can also be looked at by a full MI parser.

> and making rules like "the command will never change" 
> is non-intuitive and confusing. 

  How much experience of computer programming do you actually have?  Have
you any concept of versioning mechanisms?  Have you ever heard of an ABI, or
an "interface specification", in the context of it being a future guarantee?
What I describe is standard practice throughout the software industry and
has been for many many years.  You need to read some books or take a course
or something.  Nobody else has the conceptual difficulties you've been
getting yourself stuck in with these fundamentals.

> Having a simple mechanism, such as a command 
> line switch or a
> new interpreter, would be simple and understandable.

  This is still an invalid argument, for still the exact same reason that I
explained in my last post and you conveniently ignored because you had no
good answer for it.  You are now just repeating yourself without adding any
new content.  So I may as well repeat my explanation of the problem without
adding any new content.  Please pay attention this time:


  You claim that the problem is in having to supply an adhoc parser and make
rules like "the output will never change".  Yet _your_ proposed solution
suffers from the exact same flaw.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: probing GDB for MI versions

['Bob Rossi']

> > The MI developers, wise as they are, decided to formalize the way GDB
> > output's data and front end developers parse it.
> 
>   Your insistence on using formal parsers for every single job regardless of
> the fact that you can also see that they're not suitable for the job flies
> in the face of sanity.  You're a child with a hammer and every single
> problem looks to you like a nail.

You are inappropriate.

I clearly understand that either way an adhoc parser is involved. I
undersatnd the problem can be solved both ways, with an MI command or a
command line switch.

I understand that adding an MI command to the MI function set that can
not be accessed by a front end that understands the MI protocol is
nonsensical and confusing, that is why I am arguing on the side of not
adding this command to the MI function set, but solving the problem
another way.

Thanks,
Bob Rossi

RE: probing GDB for MI versions

[Dave Korn]

> -----Original Message-----
> From: 'Bob Rossi'
> Sent: 07 October 2004 15:37

> I understand that adding an MI command to the MI function set that can
> not be accessed by a front end that understands the MI protocol is
> nonsensical and confusing

  Since nobody has proposed such an addition, your opinion of it is utterly
irrelevant.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: probing GDB for MI versions

['Bob Rossi']

On Thu, Oct 07, 2004 at 03:50:18PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: 'Bob Rossi'
> > Sent: 07 October 2004 15:37
> 
> > I understand that adding an MI command to the MI function set that can
> > not be accessed by a front end that understands the MI protocol is
> > nonsensical and confusing
> 
>   Since nobody has proposed such an addition, your opinion of it is utterly
> irrelevant.

Again, you do not understand the issue. 

Adding this new function -mi-version, will be adding the first command 
to the MI command set that is supposed to be used by a front end by 
*not* using an MI protocol. It is confusing and non-sensical to add the
first MI command to the MI command set that can not be used by a front 
end that speaks the MI protocol.

Thanks,
Bob Rossi

Re: probing GDB for MI versions

[Nathan J. Williams]

"'Bob Rossi'" <bob@brasko.net> writes:

> Adding this new function -mi-version, will be adding the first command 
> to the MI command set that is supposed to be used by a front end by 
> *not* using an MI protocol. It is confusing and non-sensical to add the
> first MI command to the MI command set that can not be used by a front 
> end that speaks the MI protocol.

That this command is most useful to a pre-parser deciding which parser
to invoke does not mean it can't be used, or isn't useful to that
full-fledged parser. A parser whose job was validating output (in the
testsuite, say) would want to and be able to exercise it, as would a
parser that wanted to verify that it was dealing with a version of MI
it understood - and it can do that within the parse tree and formal
structure of MI.

The way you are using a parser is entirely your own choice, not
dictated by the way MI is specified; as an example, we've talked about
generated parsers and hand-written parsers for the grammar, and I'm
sure radically different approaches are also feasable. MI neural net,
anyone?

        - Nathan

Re: probing GDB for MI versions

[Alain Magloire]

> 
> On Thu, Oct 07, 2004 at 03:50:18PM +0100, Dave Korn wrote:
> > > -----Original Message-----
> > > From: 'Bob Rossi'
> > > Sent: 07 October 2004 15:37
> > 
> > > I understand that adding an MI command to the MI function set that can
> > > not be accessed by a front end that understands the MI protocol is
> > > nonsensical and confusing
> > 
> >   Since nobody has proposed such an addition, your opinion of it is utterly
> > irrelevant.
> 
> Again, you do not understand the issue. 
> 
> Adding this new function -mi-version, will be adding the first command 
> to the MI command set that is supposed to be used by a front end by 
> *not* using an MI protocol. It is confusing and non-sensical to add the
> first MI command to the MI command set that can not be used by a front 
> end that speaks the MI protocol.
> 

(I have this funny feeling, that you guys are going in circle !
 Am I missing an important piece of the puzzle ?)

Bob, I thought I was following your way of thinking but you lost me there.
One of the reason(correct me If I'm wrong) to add -mi-version is if
the front-end start gdb like this
$ gdb -i=mi executable

Doing "-mi-version" will let the front-end adjust which parser to instanciate.

But after that, you seem to get lost on implementation details, chicken and egg
problem, with reasoning like: we need to parse the "-mi-version" with an MI parser
but wait ... we can not start the parser since we do not know yet which parser to
instanciate.

Davek's point(which I tend to agree with) is saying you need to bootstap somehow.

Let's focus for a second on this issue, from the 3 scenarios below which one
will be satisfactory for you:

1- front end starts gdb with different mi version until it finds a good one
    $gdb -i=mi4  # fails
    $gdb -i=mi3  # fails
    $gdb -i=mi2  # sucess, start debuging

2- front end choose the protocol form the list of known
   $gdb --list-protocols
   
3- the -mi-version


(1) looks allright and no changes is needed
(2) could be nicer
(3) is ok.

RE: probing GDB for MI versions

[Dave Korn]

> -----Original Message-----
> From: 'Bob Rossi' [mailto:bob@brasko.net] 
> Sent: 07 October 2004 15:55

> On Thu, Oct 07, 2004 at 03:50:18PM +0100, Dave Korn wrote:
> > > -----Original Message-----
> > > From: 'Bob Rossi'
> > > Sent: 07 October 2004 15:37
> > 
> > > I understand that adding an MI command to the MI function 
> set that can
> > > not be accessed by a front end that understands the MI protocol is
> > > nonsensical and confusing
> > 
> >   Since nobody has proposed such an addition, your opinion 
> of it is utterly
> > irrelevant.
> 
> Again, you do not understand the issue. 

  Again, you ignore the words that are actually right in front of your eyes
when you write your reply.

 -  I have never said what you repeatedly claim I have said.
 -  Therefore anything to do with that suggestion (the one which I did _NOT_
make, rather than the one which I _did_ make) is outside the current
discussion.
 -  I do not need to address anything that is outside the current
discussion.
 -  Therefore I have no need to "understand the issue" in question.

[Entire paragraph's-worth of sarcasm removed after thinking better of it
here.  See, I am _trying_ to be reasonable.  Shame though, some of it was
quite cutting and witty.]

> Adding this new function -mi-version, will be adding the 
> first command 
> to the MI command set that is supposed to be used by a front end by 
> *not* using an MI protocol.

  This is an entirely arbitrary claim which you appear to have just
invented.  I never suggested such a thing.  Please stop tilting at strawmen.

> It is confusing and non-sensical 
> to add the
> first MI command to the MI command set that can not be used 
> by a front 
> end that speaks the MI protocol.

  If you're going to abuse the meaning of the words "can not" like that, we
aren't even speaking the same language.  There's *nothing* about the
"-mi-version" command that prevents it from being "used by a front end that
speaks the MI protocol".  It *can* be used, and in *exactly* the same way as
it would send *any* other MI command and parse the reply.  So your sentence
should have said "can" where it currently says "can not", at least if you
wanted it to be correct.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: probing GDB for MI versions

[Felix Lee]

'Bob Rossi' <bob@brasko.net>:
> I understand that adding an MI command to the MI function set that can
> not be accessed by a front end that understands the MI protocol is
> nonsensical and confusing, that is why I am arguing on the side of not
> adding this command to the MI function set, but solving the problem
> another way.

... I'm lost.  if I apply your statement to a different context,
you seem to be saying that gdb's "show version" command is a
nonsensical and confusing way of determining what version gdb is,
and there should be an out-of-band method of determining gdb
version.

this seems to me obviously wrong, because there are many
situations where you're limited to serial communication with a
remote agent, so it isn't possible to get out-of-band
information.

that situation is unlikely to happen with gdb itself, since in
any sane situation you're going to be able to invoke gdb with
arbitrary command switches.  but that's unusual rather than
typical.  most communication protocols need an in-band method of
determining protocol version.

it's not clear to me what assumptions you're making that lead you
to dramatically different conclusions about what's "obvious".
--

Re: probing GDB for MI versions

[Bob Rossi]

On Thu, Oct 07, 2004 at 10:12:40AM -0700, Felix Lee wrote:
> 'Bob Rossi' <bob@brasko.net>:
> > I understand that adding an MI command to the MI function set that can
> > not be accessed by a front end that understands the MI protocol is
> > nonsensical and confusing, that is why I am arguing on the side of not
> > adding this command to the MI function set, but solving the problem
> > another way.
> 
> ... I'm lost.  if I apply your statement to a different context,
> you seem to be saying that gdb's "show version" command is a
> nonsensical and confusing way of determining what version gdb is,
> and there should be an out-of-band method of determining gdb
> version.
> 
> this seems to me obviously wrong, because there are many
> situations where you're limited to serial communication with a
> remote agent, so it isn't possible to get out-of-band
> information.
> 
> that situation is unlikely to happen with gdb itself, since in
> any sane situation you're going to be able to invoke gdb with
> arbitrary command switches.  but that's unusual rather than
> typical.  most communication protocols need an in-band method of
> determining protocol version.

I am not sure when you say "out of band", if you are refering to 
GDB/MI's out of band record in the MI output syntax.

I do understand what you are saying, and I agree with you. Some
protocols allow for the version communication to take place within the
protocol. This makes the most sense to me.

For instance, XML allows the first line of the document to have the
version number. From then on, it can use the correct parser to process
the document. If the version number is not there, it can only guess at
what's in the document, and errors can occcur. Basically, the version
number is in a format the client can understand and then the client can
choose the appropriate parser based off of this.

I think adding an MI command to get the version is not the solution to
this problem. Calling an MI command assumes that you already know the
protocol, and then you can call the MI function. Otherwise, you are not
necessarily handshaking, but you have to write the adhoc parser to get
the information you need.

For instance, if GDB supported 1 stable MI protocol, if it is an
official release or a CVS snapshot, then the first thing GDB could
output to the front end is the version of MI that it is communicating.

If we wanted to be even more verbose, we could 

   * define a syntax for an MI header that communicated to the front 
     end all of the necessary things it would need to know before 
     initializing it's protocol.

   * we could always handshake using the MI2 protocol, even though the
     protocol that GDB supports is a higher version. 
     
For option 2, this means that GDB would not necessarily support MI2, 
but it would handshake in that protocol, since it will probably never 
need to change for backward incompatibilities. This has the downside 
of forcing new front ends to be able to implement the MI2 protocol, 
which is probably not a good idea.

Any comments?

Thanks,
Bob Rossi

Re: probing GDB for MI versions

['Bob Rossi']

On Thu, Oct 07, 2004 at 12:14:00PM -0400, Alain Magloire wrote:
> > 
> > On Thu, Oct 07, 2004 at 03:50:18PM +0100, Dave Korn wrote:
> > > > -----Original Message-----
> > > > From: 'Bob Rossi'
> > > > Sent: 07 October 2004 15:37
> > > 
> > > > I understand that adding an MI command to the MI function set that can
> > > > not be accessed by a front end that understands the MI protocol is
> > > > nonsensical and confusing
> > > 
> > >   Since nobody has proposed such an addition, your opinion of it is utterly
> > > irrelevant.
> > 
> > Again, you do not understand the issue. 
> > 
> > Adding this new function -mi-version, will be adding the first command 
> > to the MI command set that is supposed to be used by a front end by 
> > *not* using an MI protocol. It is confusing and non-sensical to add the
> > first MI command to the MI command set that can not be used by a front 
> > end that speaks the MI protocol.
> > 
> 
> (I have this funny feeling, that you guys are going in circle !
>  Am I missing an important piece of the puzzle ?)
> 
> Bob, I thought I was following your way of thinking but you lost me there.
> One of the reason(correct me If I'm wrong) to add -mi-version is if
> the front-end start gdb like this
> $ gdb -i=mi executable
> 
> Doing "-mi-version" will let the front-end adjust which parser to instanciate.

Yes, asking GDB what version is supports allows the front end to chose a
parser that can handle the MI protocol.

> But after that, you seem to get lost on implementation details, chicken and egg
> problem, with reasoning like: we need to parse the "-mi-version" with an MI parser
> but wait ... we can not start the parser since we do not know yet which parser to
> instanciate.

Yes.

> Davek's point(which I tend to agree with) is saying you need to bootstap somehow.

Yes, you need to bootstrap, I agree.

> Let's focus for a second on this issue, from the 3 scenarios below which one
> will be satisfactory for you:
> 
> 1- front end starts gdb with different mi version until it finds a good one
>     $gdb -i=mi4  # fails
>     $gdb -i=mi3  # fails
>     $gdb -i=mi2  # sucess, start debuging

This is possible, yet is obviously ugly. Imagine MI 1000 :)
Also, GDB starts up it's development version of MI when you ask it to.

> 2- front end choose the protocol form the list of known
>    $gdb --list-protocols

I like this solution. 
However, I understand that not everyone does and I can see why.

> 3- the -mi-version

I do not like this solution. I do not like adding an MI command to the
MI function set that is not intended to be parsed by a front end that
can speak the MI protocol. I've stated that this is confusing and
nonsensical.

I understand that the new mi command could be called by a front end that
speaks the MI protocol, but only after the front end new which MI
protocol to speak. The front end would have to come up with an adhoc
parser for getting the information that it needs, and this would be the
first and only MI command that has to be used like this.

Finally, there are several other solutions,

   * An interpreter that only outputs the mi versions
   * A handshaking protocol 
   * Have GDB output it's last stable version of MI as the first thing
     it outputs (subset of case above)

Thanks,
Bob Rossi

Thanks,
Bob Rossi

Re: probing GDB for MI versions

[Fabian Cenedese]

>For instance, XML allows the first line of the document to have the
>version number. From then on, it can use the correct parser to process
>the document. If the version number is not there, it can only guess at
>what's in the document, and errors can occcur. Basically, the version
>number is in a format the client can understand and then the client can
>choose the appropriate parser based off of this.
>
>I think adding an MI command to get the version is not the solution to
>this problem. Calling an MI command assumes that you already know the
>protocol, and then you can call the MI function. Otherwise, you are not
>necessarily handshaking, but you have to write the adhoc parser to get
>the information you need.
>
>For instance, if GDB supported 1 stable MI protocol, if it is an
>official release or a CVS snapshot, then the first thing GDB could
>output to the front end is the version of MI that it is communicating.
>
>If we wanted to be even more verbose, we could 
>
>   * define a syntax for an MI header that communicated to the front 
>     end all of the necessary things it would need to know before 
>     initializing it's protocol.
>
>   * we could always handshake using the MI2 protocol, even though the
>     protocol that GDB supports is a higher version. 
>     
>For option 2, this means that GDB would not necessarily support MI2, 
>but it would handshake in that protocol, since it will probably never 
>need to change for backward incompatibilities. This has the downside 
>of forcing new front ends to be able to implement the MI2 protocol, 
>which is probably not a good idea.

Another example is the Auto-sense of Ethernet. Two partners start
communicating with 10MBit as the least common denominator of
Ethernet. Then they find they can both speak 100MBit and switch
to this. Compared to gdb this would mean to start gdb with mi1,
negotiate the version and then possibly switch to some higher
mi version. But I think the switching is the part that doesn't work
here (without restarting gdb, correct me if I'm wrong). 

Is it possbile to switch the mi version on the fly? If not, is this even
considered a possible future extension? Or is it considered unneeded
and wasted manpower as a working solution (restarting gdb) already
exists?

(I don't need this for myself. As I have to deliver a cross-compiled
gdb with possibly some changes I will always know what mi version
it can speak.)

Thanks

bye  Fabi

Re: probing GDB for MI versions

[Eli Zaretskii]

> Date: Thu, 7 Oct 2004 18:42:30 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> Cc: Dave Korn <dk@artimi.com>, gdb@sources.redhat.com
> 
>    * Have GDB output it's last stable version of MI as the first thing
>      it outputs (subset of case above)

Will this solution be satisfactory for you?  That is, when invoked
with the -interpreter=mi<N> command-line switch, GDB will print the
last stable version of the MI protocol it supports.  This is actually
the way many protocol negotiations start, and I don't see why we
shouldn't behave the same.

Note that a front end which wants to support older GDB versions will
need to have a database of MI versions referenced by GDB versions,
because the old GDB versions will not print the MI version.

Are there any disadvantages to this solution?

Re: probing GDB for MI versions

[Eli Zaretskii]

> Date: Wed, 06 Oct 2004 16:09:42 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: GDB <gdb@sources.redhat.com>
> 
> I'm simply pointing out the obvious - what we don't test [likely] 
> doesn't work.

Well, that's true, but there _are_ tests for mi1 in testsuite/gdb.mi.

Re: probing GDB for MI versions

[Daniel Jacobowitz]

On Fri, Oct 08, 2004 at 11:06:36AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 06 Oct 2004 16:09:42 -0400
> > From: Andrew Cagney <cagney@gnu.org>
> > Cc: GDB <gdb@sources.redhat.com>
> > 
> > I'm simply pointing out the obvious - what we don't test [likely] 
> > doesn't work.
> 
> Well, that's true, but there _are_ tests for mi1 in testsuite/gdb.mi.

Removed on 2004-02-13...

-- 
Daniel Jacobowitz

Re: probing GDB for MI versions

['Bob Rossi']

On Fri, Oct 08, 2004 at 10:36:45AM +0200, Eli Zaretskii wrote:
> > Date: Thu, 7 Oct 2004 18:42:30 -0400
> > From: 'Bob Rossi' <bob@brasko.net>
> > Cc: Dave Korn <dk@artimi.com>, gdb@sources.redhat.com
> > 
> >    * Have GDB output it's last stable version of MI as the first thing
> >      it outputs (subset of case above)
> 
> Will this solution be satisfactory for you?  That is, when invoked
> with the -interpreter=mi<N> command-line switch, GDB will print the
> last stable version of the MI protocol it supports.  This is actually
> the way many protocol negotiations start, and I don't see why we
> shouldn't behave the same.
> 
> Note that a front end which wants to support older GDB versions will
> need to have a database of MI versions referenced by GDB versions,
> because the old GDB versions will not print the MI version.
> 
> Are there any disadvantages to this solution?

Sorry for the delay, I am waiting on the answer for these questions
   http://sources.redhat.com/ml/gdb/2004-10/msg00267.html
before I can say if this will be OK for me.

Bob Rossi

Re: probing GDB for MI versions

['Bob Rossi']

On Fri, Oct 08, 2004 at 08:29:01PM -0400, 'Bob Rossi' wrote:
> On Fri, Oct 08, 2004 at 10:36:45AM +0200, Eli Zaretskii wrote:
> > > Date: Thu, 7 Oct 2004 18:42:30 -0400
> > > From: 'Bob Rossi' <bob@brasko.net>
> > > Cc: Dave Korn <dk@artimi.com>, gdb@sources.redhat.com
> > > 
> > >    * Have GDB output it's last stable version of MI as the first thing
> > >      it outputs (subset of case above)
> > 
> > Will this solution be satisfactory for you?  That is, when invoked
> > with the -interpreter=mi<N> command-line switch, GDB will print the
> > last stable version of the MI protocol it supports.  This is actually
> > the way many protocol negotiations start, and I don't see why we
> > shouldn't behave the same.
> > 
> > Note that a front end which wants to support older GDB versions will
> > need to have a database of MI versions referenced by GDB versions,
> > because the old GDB versions will not print the MI version.
> > 
> > Are there any disadvantages to this solution?
> 
> Sorry for the delay, I am waiting on the answer for these questions
>    http://sources.redhat.com/ml/gdb/2004-10/msg00267.html
> before I can say if this will be OK for me.
> 
> Bob Rossi

OK, I have received an answer. Basically GDB has already, and may in the
future support multiple versions of MI. The solution above is perfect if
GDB supports one stable version of MI, however, if it supports multiple
versions of MI, the front end still needs to tell GDB which version it
wants to use. 

I have come up with a crude patch that makes GDB work like this,
the '>' means that GDB is outputting data to the front end, and the '<'
means that GDB is inputting data from the front end.

   $ ./gdb -i=mi-handshake
   >mi1
   >mi2
   >mi3
   <mi2
   >~"GNU gdb 6.2.50_2004-10-08-cvs\n"
   >...
   >(gdb)

Basically, just to get the idea, GDB outputs all of the MI front end's
that it supports, and then allows the front end to choose one. All of
this happens before GDB initializes the interpreter, so that after the
choice is made, GDB does not have to be restarted and will work with the
protocol selected by the front end.

Any ideas?

Obviously we could define the handshaking better, and allow for
development vs stable releases to be made clear. Also, make room for
future extensions and make a grammar, ..

Thanks,
Bob Rossi

Re: probing GDB for MI versions

['Bob Rossi']

On Fri, Oct 08, 2004 at 08:29:01PM -0400, 'Bob Rossi' wrote:
> On Fri, Oct 08, 2004 at 10:36:45AM +0200, Eli Zaretskii wrote:
> > > Date: Thu, 7 Oct 2004 18:42:30 -0400
> > > From: 'Bob Rossi' <bob@brasko.net>
> > > Cc: Dave Korn <dk@artimi.com>, gdb@sources.redhat.com
> > > 
> > >    * Have GDB output it's last stable version of MI as the first thing
> > >      it outputs (subset of case above)
> > 
> > Will this solution be satisfactory for you?  That is, when invoked
> > with the -interpreter=mi<N> command-line switch, GDB will print the
> > last stable version of the MI protocol it supports.  This is actually
> > the way many protocol negotiations start, and I don't see why we
> > shouldn't behave the same.
> > 
> > Note that a front end which wants to support older GDB versions will
> > need to have a database of MI versions referenced by GDB versions,
> > because the old GDB versions will not print the MI version.
> > 
> > Are there any disadvantages to this solution?
> 
> Sorry for the delay, I am waiting on the answer for these questions
>    http://sources.redhat.com/ml/gdb/2004-10/msg00267.html
> before I can say if this will be OK for me.

Let's start smaller, everyone seems to be happy with the handshaking
idea. Any objections?

With this idea there are 2 alternatives I can think of.
   * put the handshaking under a different interpreter (-i=mi-handshake)
   * integrate the handshaking as part of the MI protocol (version 3 and on)

I kind of prefer having to call the mi-handshake interpreter explicitly,
and not making it part of the MI protocol. This way, if a front end
wants to start mi3 or any other protocol, they can explicitly state it.
For example, gdb -i=mi3 will start MI protocol version 3 like it always
has. There should be no handshaking involved if the front end selects a
specific version.  If a front end wants to go into handshaking mode to
select a protocol, it can explicitly ask to do so. (gdb -i=mi-handshake)

This is the solution to the problem that I would like to implement, any
objections?

Thanks,
Bob Rossi

Re: probing GDB for MI versions

[Eli Zaretskii]

> Date: Tue, 12 Oct 2004 20:31:35 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> 
> With this idea there are 2 alternatives I can think of.
>    * put the handshaking under a different interpreter (-i=mi-handshake)
>    * integrate the handshaking as part of the MI protocol (version 3 and on)

What's wrong with a simpler idea already suggested here: that GDB will
output the MI version as part of the starting blurb when invoked with
"-interpreter=mi" option?

Re: probing GDB for MI versions

['Bob Rossi']

On Wed, Oct 13, 2004 at 06:47:37AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 12 Oct 2004 20:31:35 -0400
> > From: 'Bob Rossi' <bob@brasko.net>
> > 
> > With this idea there are 2 alternatives I can think of.
> >    * put the handshaking under a different interpreter (-i=mi-handshake)
> >    * integrate the handshaking as part of the MI protocol (version 3 and on)
> 
> What's wrong with a simpler idea already suggested here: that GDB will
> output the MI version as part of the starting blurb when invoked with
> "-interpreter=mi" option?

That method is fine if GDB supports only one stable MI protocol at a
time. However, I have been told that GDB will support multiple versions
of MI at a time.

If GDB supported only one stable MI version at a time, then it could
just do what you are saying, tell the front end what version it is going
to output. This is basically how XML and HTML documents work. The first
line is the version of the file, and the client reads that and uses the
appropriate parser.

However, GDB is not that simple. It can support several versions of the
MI protocol. Some of the versions can be developmental, others can be
stable, and others can be unstable. For instance, the current GDB has
mi2 being stable, and mi1 being unstable (not tested). For this reason,
GDB and the front end actually need to handshake to determine what
protocol should be used. I'm assuming that this is more like the
Ethernet example someone brought up were all of the devices have to
query each other to figure out what protocol to use.

Here is something I came up with last night,

   GDB/MI Handshaking output

   mi-handshake-input  => mi-protocol-output [ "," mi-protocol-output ]* nl
   mi-protocol-output  => mi-protocol-class "=" mi-protocol
   mi-protocol-class   => "mi_unsupported" | "mi_supported" | "mi_development"
   mi-protocol         => "mi" digit
   digit               => 1 | 1 + digit
   nl                  => CR | CR NL | NL

   GDB/MI Handshaking input

   mi-handshake-input => mi-protocol nl

Obviously, that results in GDB outputting something like,
   mi_unsupported=mi1,mi_supported=mi2,mi_development=mi3
and the front end sending to GDB simply "mi2".

Thanks,
Bob Rossi

Re: probing GDB for MI versions

[Eli Zaretskii]

> Date: Wed, 13 Oct 2004 08:14:12 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> Cc: gdb@sources.redhat.com
> 
> > What's wrong with a simpler idea already suggested here: that GDB will
> > output the MI version as part of the starting blurb when invoked with
> > "-interpreter=mi" option?
> 
> That method is fine if GDB supports only one stable MI protocol at a
> time. However, I have been told that GDB will support multiple versions
> of MI at a time.

Yes, but Andrew just told you that GDB will most probably support at
most 2 MI versions: the latest one and the one before that.  So
printing only the last version is okay, because if that version is not
supported by your front end, you need only to check the previous
version.  Isn't that good enough?

(Even if GDB does support more than 2 MI versions, you could still
probe smaller versions until you either (1) find one that is okay with
your front end, or (2) get GDB to fail because the MI version you
requested is not supported.

And if that is still not good enough, let's have GDB output a list of
supported MI versions as part of its starting blurb, e.g. one version
per line.

Will that finally put this issue to rest?

Re: probing GDB for MI versions

['Bob Rossi']

On Wed, Oct 13, 2004 at 10:29:31PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 13 Oct 2004 08:14:12 -0400
> > From: 'Bob Rossi' <bob@brasko.net>
> > Cc: gdb@sources.redhat.com
> > 
> > > What's wrong with a simpler idea already suggested here: that GDB will
> > > output the MI version as part of the starting blurb when invoked with
> > > "-interpreter=mi" option?
> > 
> > That method is fine if GDB supports only one stable MI protocol at a
> > time. However, I have been told that GDB will support multiple versions
> > of MI at a time.
> 
> Yes, but Andrew just told you that GDB will most probably support at
> most 2 MI versions: the latest one and the one before that.  So
> printing only the last version is okay, because if that version is not
> supported by your front end, you need only to check the previous
> version.  Isn't that good enough?
>
> (Even if GDB does support more than 2 MI versions, you could still
> probe smaller versions until you either (1) find one that is okay with
> your front end, or (2) get GDB to fail because the MI version you
> requested is not supported.

I can give several reasons why this is not good enough. As far as I can
tell, there are 3 types of MI protocols. Supported, unsupported and
developmental. This information needs to be given to the front end. For
example, right now GDB supports MI2. However, if a front end understood
only MI1, then it would be tempted to try MI1 with your approach.
However, MI1 is unsupported and most likely doesn't work. It would be
nice if the front end was capable of understanding that.

> And if that is still not good enough, let's have GDB output a list of
> supported MI versions as part of its starting blurb, e.g. one version
> per line.

This seems reasonable. There are 2 down sides that I don't like

   * There is no handshaking being done. Average case scenario is starting
     GDB twice to get it into the correct mode. Once to find out the
     supported versions, second to start it in the correct mode.

   * It tells the front end only the minimum information it needs to
     know. (developmental and unsupported interfaces are not printed)
     Again, this probably isn't to important.

If we implement the handshaking solution that I had, it is guaranteed that 
the front end will be able to start GDB only once and get it into the 
correct MI protocol.

What is wrong with the handshaking protocol that I described? I see it
as the optimal solution and would be happy to implement it.

> Will that finally put this issue to rest?

I understand this issue is long and drawn out, however, it is critical 
for a front end to GDB that plans on working with multiple GDB's and 
not just one that is bundled together.

Thanks for helping out!

Thanks,
Bob Rossi

Re: probing GDB for MI versions

[Andrew Cagney]

>>> Yes, but Andrew just told you that GDB will most probably support at
>>> most 2 MI versions: the latest one and the one before that.  So
>>> printing only the last version is okay, because if that version is not
>>> supported by your front end, you need only to check the previous
>>> version.  Isn't that good enough?
>>>
>>> (Even if GDB does support more than 2 MI versions, you could still
>>> probe smaller versions until you either (1) find one that is okay with
>>> your front end, or (2) get GDB to fail because the MI version you
>>> requested is not supported.

Yes, it's good enough.  Either:

- GDB is started with -i=mi; gdb reports its version (if anything I'd be 
relying on the GDB and not the MI version); your code adjusts
- GDB is started with -i=miX; gdb either barfs or soldiers on; your code 
adjusts

Andrew

Re: probing GDB for MI versions

[Eli Zaretskii]

> Date: Thu, 14 Oct 2004 11:37:20 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> Cc: gdb@sources.redhat.com
> 
> > Yes, but Andrew just told you that GDB will most probably support at
> > most 2 MI versions: the latest one and the one before that.  So
> > printing only the last version is okay, because if that version is not
> > supported by your front end, you need only to check the previous
> > version.  Isn't that good enough?
> >
> > (Even if GDB does support more than 2 MI versions, you could still
> > probe smaller versions until you either (1) find one that is okay with
> > your front end, or (2) get GDB to fail because the MI version you
> > requested is not supported.
> 
> I can give several reasons why this is not good enough. As far as I can
> tell, there are 3 types of MI protocols. Supported, unsupported and
> developmental.

I was only talking about stable versions, so developmental is not
something we should consider (we've been through this and decided that
it is unsafe to use such versions).

> This information needs to be given to the front end. For
> example, right now GDB supports MI2. However, if a front end understood
> only MI1, then it would be tempted to try MI1 with your approach.
> However, MI1 is unsupported and most likely doesn't work.

If MI1 is not working and the front end only supports MI1, then this
combination of GDB and front end is not going to work.  So I submit
that this case is not interesting: you will try MI1 and things will go
wrong at some point.

However, ``unsupported'' and ``doesn't work'' are not the same thing.
If we know that a certain version of MI does not work, we should
remove its support from GDB.  If we didn't do that, then we have good
reasons to believe that MI1 does in fact work.

> It would be
> nice if the front end was capable of understanding that.

And then do what? print a message "like unsupported GDB version"?  Is
this really an interesting case?  I thought you were interested in
getting a front end to _work_ with MI; graceful failure is something
different.  Can we please solve one problem at a time?  Do you agree
that if either (1) the front end supports the latest stable version or
(2) the version before that works reasonably well, then printing only
the latest stable version at startup is good enough?

> This seems reasonable. There are 2 down sides that I don't like
> 
>    * There is no handshaking being done. Average case scenario is starting
>      GDB twice to get it into the correct mode. Once to find out the
>      supported versions, second to start it in the correct mode.

I don't see this as a grave problem.

>    * It tells the front end only the minimum information it needs to
>      know. (developmental and unsupported interfaces are not printed)
>      Again, this probably isn't to important.

Indeed.

> What is wrong with the handshaking protocol that I described?

It is too complicated for the job, IMHO.

Re: probing GDB for MI versions

[Michael Chastain]

gcc has many options with similar purposes:

  -print-file-name=LIBRARY
    Print the full absolute name of the library file LIBRARY
    that would be used when linking--and don't do anything else.
    With this option, GCC does not compile or link anything;
    it just prints the file name.

  -print-multi-directory
    Print the directory name corresponding to the multilib selected
    by any other switches present in the command line.   [et cetera]

  -print-multi-lib
    Print the mapping from multilib directory names to compiler
    switches that enable them.  [et cetera]

  -print-prog-name=PROGRAM
    Like -print-file-name, but searches for a program such as cpp.

  -print-libgcc-file-name
    [et cetera]

  -print-search-dirs
    [et cetera]

  -dumpmachine
  -dumpversion
  -dumpspecs
    [et cetera]

This situation looks very similar.  So if -print-XXX and --dumpYYY
are working well for gcc, then "gdb -print-mi-versions" ought to
be fine.  Like Bob, I don't have a problem with invoking gdb twice.

Just my two cents,

Michael

Re: probing GDB for MI versions

[Eli Zaretskii]

> Date: Thu, 14 Oct 2004 22:36:46 -0400
> From: Michael Chastain <mec.gnu@mindspring.com>
> Cc: gdb@sources.redhat.com
> 
> gcc has many options with similar purposes:

GCC is not an interactive program, so it has no other way to do that.
Not so in the case of GDB.

Re: probing GDB for MI versions

['Bob Rossi']

On Thu, Oct 14, 2004 at 02:53:29PM -0400, Andrew Cagney wrote:
> 
> >>>Yes, but Andrew just told you that GDB will most probably support at
> >>>most 2 MI versions: the latest one and the one before that.  So
> >>>printing only the last version is okay, because if that version is not
> >>>supported by your front end, you need only to check the previous
> >>>version.  Isn't that good enough?
> >>>
> >>>(Even if GDB does support more than 2 MI versions, you could still
> >>>probe smaller versions until you either (1) find one that is okay with
> >>>your front end, or (2) get GDB to fail because the MI version you
> >>>requested is not supported.
> 
> Yes, it's good enough.  Either:
> 
> - GDB is started with -i=mi; gdb reports its version (if anything I'd be 
> relying on the GDB and not the MI version); your code adjusts

This case does not make sense for the task I am hoping to accomplish. 
It does not allow the front end to figure out what tested versions of 
the MI protocol a particular GDB supports.

The only thing this does is tell the front end what version of MI that
GDB will be speaking. This is necesary but it is a different problem
than I am trying to solve.

If you added this to the MI protocol, which I think it should be, it
still does not solve the problem of finding out what tested versions of
the MI protocol GDB supports.

> - GDB is started with -i=miX; gdb either barfs or soldiers on; your code 
> adjusts

Yes, this case makes sense. I am not interested in the case were the
user asks for a particular version of the MI protocol.

Thanks,
Bob Rossi

Re: probing GDB for MI versions

['Bob Rossi']

> I was only talking about stable versions, so developmental is not
> something we should consider (we've been through this and decided that
> it is unsafe to use such versions).

Yes, you are correct.

> > This information needs to be given to the front end. For
> > example, right now GDB supports MI2. However, if a front end understood
> > only MI1, then it would be tempted to try MI1 with your approach.
> > However, MI1 is unsupported and most likely doesn't work.
> 
> If MI1 is not working and the front end only supports MI1, then this
> combination of GDB and front end is not going to work.  So I submit
> that this case is not interesting: you will try MI1 and things will go
> wrong at some point.
> 
> However, ``unsupported'' and ``doesn't work'' are not the same thing.
> If we know that a certain version of MI does not work, we should
> remove its support from GDB.  If we didn't do that, then we have good
> reasons to believe that MI1 does in fact work.

I think that supported(tested) and unsupported(untested) are two
entirely different things. Users should not be responsible for finding
bugs in the MI protocol because GDB said that a front end could use a
depricated protocol. It's just not fair. Also, above and beyond that, I
do not want my front end to work with untested versions of the MI
protocol, it would simply make me look bad when things stopped working
half way throuh a session.

> > It would be
> > nice if the front end was capable of understanding that.
> 
> And then do what? print a message "like unsupported GDB version"?  Is
> this really an interesting case?  

I consider this a very interesting case.

> I thought you were interested in
> getting a front end to _work_ with MI; graceful failure is something
> different.  Can we please solve one problem at a time?  Do you agree
> that if either (1) the front end supports the latest stable version or
> (2) the version before that works reasonably well, then printing only
> the latest stable version at startup is good enough?

No, I can not agree to that. Again, like I said to andrew, printing the
latest stable version simply is common sense. It allows the front end to
determine if it can work with the current GDB. It is a different problem
than probing GDB to determine what MI versions that it supports.

Especially the second case that you have posted makes no sense to me,
"the version before works reasonably well". I don't want a reasonably
well working verion, I want a version that it tested in the testsuite.

> > This seems reasonable. There are 2 down sides that I don't like
> > 
> >    * There is no handshaking being done. Average case scenario is starting
> >      GDB twice to get it into the correct mode. Once to find out the
> >      supported versions, second to start it in the correct mode.
> 
> I don't see this as a grave problem.
> 
> >    * It tells the front end only the minimum information it needs to
> >      know. (developmental and unsupported interfaces are not printed)
> >      Again, this probably isn't to important.
> 
> Indeed.
> 
> > What is wrong with the handshaking protocol that I described?
> 
> It is too complicated for the job, IMHO.

Can I sum up the solutions we have, because it's obvious that we are not
interested in solving the problem the same way. You and I are on the
opposite side of each different type of solution that we come up with
and this is why it is taking a very long time to reach a middle point.

* printing just the latest stable version

   Is this the version that GDB will start up in if you do -i=mi even if
   you are using a CVS snapshot and the version has been bumped?

   This solution is lacking. It only tells the front end the latest
   stable version of the MI protocol. The front end can only guess what
   other stable versions are available and I consider this unacceptable.

   For CVS snapshots, if the above questions is true, then it will
   always print out the latest stable version and it will be
   communicating not in that version. This requires a restart no matter
   what.

   This does not satisfy the minimum amount of information that I need.

* printing all of the tested MI versions.

   This solution is basically my 'command line switch' solution.

   This is the minimum information that I need. A front end that
   wants to work with GDB will need to know every version of the MI
   protocol that the particular GDB was tested with.

   However, this solution requires starting GDB twice, which I would not
   prefer if it was solvable with just starting it once.

* creating a handshaking protocol

   This is the optimal solution since it gives the front end all of the
   tested MI versions and then allows the front end to select which
   version GDB should use. This is the solution I prefer. It requires
   GDB asking the front end for the version, and the other solutions do
   not require this.

   It could be as simple as outputting all of the tested MI versions one
   line at a time and then allowing the front end to select one or it
   could be more complicated like the grammar that I posted earlier.

Thanks,
Bob Rossi

Re: probing GDB for MI versions

[Eli Zaretskii]

> Date: Fri, 15 Oct 2004 11:40:17 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> Cc: gdb@sources.redhat.com
> 
> I think that supported(tested) and unsupported(untested) are two
> entirely different things.

Not entirely: an MI version does not become buggy just because you
stop testing it.  The bit-rotting process takes time, and during that
time the untested MI is still working reasonably well.

Also, the fact that something is tested does not mean there are no
bugs in it.

So let's stop talking about absolutes because they are not appropriate
here.  Let's keep the discussion focused on practical problems, not on
principles.

> > > It would be
> > > nice if the front end was capable of understanding that.
> > 
> > And then do what? print a message "like unsupported GDB version"?  Is
> > this really an interesting case?  
> 
> I consider this a very interesting case.

More interesting than the case where the front end _can_ find a
working MI version?

> I don't want a reasonably well working verion, I want a version that
> it tested in the testsuite.

Then you must make sure your front end supports the latest stable
version, and only that version, and this whole discussion is mostly
irrelevant, because just printing the latest stable version is all you
need (if the front end doesn't support that version, it should refuse
to work).  See below.

> * printing just the latest stable version
> 
>    Is this the version that GDB will start up in if you do -i=mi even if
>    you are using a CVS snapshot and the version has been bumped?

No.  The latest stable version is not the one that is invoked with
"-i=mi", it is the stable version before that.

>    This solution is lacking. It only tells the front end the latest
>    stable version of the MI protocol. The front end can only guess what
>    other stable versions are available and I consider this unacceptable.

According to what Andrew said, and since you don't want to use
untested old versions, the latest stable version is all you need.

>    However, this solution requires starting GDB twice, which I would not
>    prefer if it was solvable with just starting it once.

I don't see any problem in restart, if that is indeed required.
However, it sounds like a restart will not be needed, since the front
end supports only one version: the latest stable one.

Again, if you are unprepared to work with any MI version but the ones
that are actively tested by the testsuite, then your front end will
need constant work to make it support the latest stable version, and
it should refuse to work with any other version.

Re: probing GDB for MI versions

['Bob Rossi']

> > I don't want a reasonably well working verion, I want a version that
> > it tested in the testsuite.
> 
> Then you must make sure your front end supports the latest stable
> version, and only that version, and this whole discussion is mostly
> irrelevant, because just printing the latest stable version is all you
> need (if the front end doesn't support that version, it should refuse
> to work).  See below.

OK, here's where I think you and I are not on the same level. This is
the fundamental problem in our discussion and why we can not agree on a
solution. Please correct me if I'm wrong here.

You think that GDB does and will only test one version of the MI
protocol. If this is true, then I would be happy to implement your
solution of printing the latest stable version and starting that version
with -i=mi. This conversation could be over with :)

However, as far as I understand it, this is not true. GDB has, and in
the future could be shipped with several versions of the MI protocol
being tested. Here is the question and answer I got from Andrew,

   * Will GDB support more than one stable MI protocols for an official release?
   In the past GDB tested both mi1 and mi2 so that that stage they were 
   probably described as "supported". Now that only mi2 is tested, nad mi1 is 
   deprecated, your call.

With this in mind, I do not think it is OK to print the latest stable
version only. It does not tell the front end what other versions could
be stable. In order for a front end to determine the protocol to use, it
needs a list of all the tested MI protocols. After that, selecting the
appropriate protocol seems like a nice thing to allow front ends to do,
thus not having to restart GDB. This seems like a natural extension to
the MI protocol and IMHO should have been around from the start.

If there indeed is more than one tested version of the MI protocol,
would you agree to me implementing the handshaking protocol? or are you
against that either way?

> >    This solution is lacking. It only tells the front end the latest
> >    stable version of the MI protocol. The front end can only guess what
> >    other stable versions are available and I consider this unacceptable.
> 
> According to what Andrew said, and since you don't want to use
> untested old versions, the latest stable version is all you need.

I posted the Q/A above that makes me think that what you are saying here
is not correct. However, please do correct me if I'm wrong.

Thanks for your time,
Bob Rossi

Re: probing GDB for MI versions

[Eli Zaretskii]

> Date: Sat, 16 Oct 2004 11:46:11 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> Cc: gdb@sources.redhat.com
> 
> You think that GDB does and will only test one version of the MI
> protocol.

It's not what I think, it's what Andrew said was the policy.

>    * Will GDB support more than one stable MI protocols for an official release?
>    In the past GDB tested both mi1 and mi2 so that that stage they were 
>    probably described as "supported". Now that only mi2 is tested, nad mi1 is 
>    deprecated, your call.
> 
> With this in mind, I do not think it is OK to print the latest stable
> version only. It does not tell the front end what other versions could
> be stable.

IIRC, MI1's tests were removed from the CVS as soon as MI2 was deemed
stable enough.  So this example doesn't conflict with what I said.

Anyway, I already suggested to have a list of versions printed at
startup time, if you still think several tested versions of MI will be
available.  We seem to go in circles since then.

Re: probing GDB for MI versions

['Bob Rossi']

On Sat, Oct 16, 2004 at 07:41:32PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 16 Oct 2004 11:46:11 -0400
> > From: 'Bob Rossi' <bob@brasko.net>
> > Cc: gdb@sources.redhat.com
> > 
> > You think that GDB does and will only test one version of the MI
> > protocol.
> 
> It's not what I think, it's what Andrew said was the policy.

He did? I thought he said "who knows", meaning he didn't know. How could
he create policy on this if he doesn't know.

   >>>   * Will GDB support more than one stable MI protocols for a CVS
   >>>   snapshot?
   Who knows,

> >    * Will GDB support more than one stable MI protocols for an official release?
> >    In the past GDB tested both mi1 and mi2 so that that stage they were 
> >    probably described as "supported". Now that only mi2 is tested, nad mi1 is 
> >    deprecated, your call.
> > 
> > With this in mind, I do not think it is OK to print the latest stable
> > version only. It does not tell the front end what other versions could
> > be stable.
> 
> IIRC, MI1's tests were removed from the CVS as soon as MI2 was deemed
> stable enough.  So this example doesn't conflict with what I said.
> 
> Anyway, I already suggested to have a list of versions printed at
> startup time, if you still think several tested versions of MI will be
> available.  We seem to go in circles since then.

Yes, I understand.

If GDB is going to support 1 stable version of the MI protocol at a time
then just have it print the version on startup. There is no negotiation
that needs to take place.

If GDB is going to support multiple stable versions of the MI protocol
at a time, then have it print all of the versions like you suggested.
Also, above what you suggested, I think the front end should be able to
select the version it wants from the list. Is this OK?

I'd like to work on this patch as soon as possible, so that I can start
using it. Is the multiple stable version approach with negotiation OK?

Thanks,
Bob Rossi

Re: probing GDB for MI versions

[Daniel Jacobowitz]

On Tue, Oct 19, 2004 at 09:19:53AM -0400, 'Bob Rossi' wrote:
> Yes, I understand.
> 
> If GDB is going to support 1 stable version of the MI protocol at a time
> then just have it print the version on startup. There is no negotiation
> that needs to take place.
> 
> If GDB is going to support multiple stable versions of the MI protocol
> at a time, then have it print all of the versions like you suggested.
> Also, above what you suggested, I think the front end should be able to
> select the version it wants from the list. Is this OK?
> 
> I'd like to work on this patch as soon as possible, so that I can start
> using it. Is the multiple stable version approach with negotiation OK?

I think it's pretty clear that no one else likes the idea of
negotiating.  I certainly don't.

I believe that printing the latest stable version of MI is plenty
adequate.  If the front end wants a development version of MI it can
use -i=mi; if it wants the latest stable version it can use that
version; if it does not recognize that version it can use the latest
version it recognizes.  If you encounter a situation in which that
version no longer works, have it removed from GDB.

-- 
Daniel Jacobowitz

Re: probing GDB for MI versions

[Bob Rossi]

On Tue, Oct 19, 2004 at 09:28:24AM -0400, Daniel Jacobowitz wrote:
> On Tue, Oct 19, 2004 at 09:19:53AM -0400, 'Bob Rossi' wrote:
> > Yes, I understand.
> > 
> > If GDB is going to support 1 stable version of the MI protocol at a time
> > then just have it print the version on startup. There is no negotiation
> > that needs to take place.
> > 
> > If GDB is going to support multiple stable versions of the MI protocol
> > at a time, then have it print all of the versions like you suggested.
> > Also, above what you suggested, I think the front end should be able to
> > select the version it wants from the list. Is this OK?
> > 
> > I'd like to work on this patch as soon as possible, so that I can start
> > using it. Is the multiple stable version approach with negotiation OK?
> 
> I think it's pretty clear that no one else likes the idea of
> negotiating.  I certainly don't.
> 
> I believe that printing the latest stable version of MI is plenty
> adequate.  If the front end wants a development version of MI it can
> use -i=mi; if it wants the latest stable version it can use that
> version; if it does not recognize that version it can use the latest
> version it recognizes.  If you encounter a situation in which that
> version no longer works, have it removed from GDB.

OK, I want to make it clear that I think this solution is terrible.
However, hoping that the GDB community knows more than I, I'll agree.

Starting GDB with -i=mi<n> will not change the MI output. However,
starting GDB with -i=mi will have GDB print the latest stable version
even though it will start GDB in it's latest development version or the
latest stable version. For some odd reason in this mode, GDB will print 
the latest stable version even though it may have absolutely nothing to 
do with the version it will be communicating with.

So, I'll basically start GDB with -i=mi and get the latest stable
version. However, since I won't know what version I just started GDB in,
the version it just spat out, or a development version, I'll *have* to
restart GDB no matter what.

So, I'll read the first line ( which is the latest stable version ), and 
then kill GDB and restart it in the mode that I support.

This solution,

   * *requires* a restart
   * requires printing the latest stable version even though GDB may not be 
     even speaking that version
   * says *nothing* about other versions that GDB supports
   * gives no way for a front end to determine if it is using a
     deprecated protocol.
   * puts the bug finding of the MI protocol on the users, even though the 
     protocols have been deprecated.

If this is the wish of the GDB community, then this is what I'll implement.

Thanks,
Bob Rossi

Re: probing GDB for MI versions

[Felix Lee]

Bob Rossi <bob@brasko.net>:
>    * *requires* a restart

there's no difference between running
    gdb -print-stable-mi-version
and running
    printf "quit\n" | gdb -interpreter=mi

>    * requires printing the latest stable version even though GDB may not be 
>      even speaking that version

'gdb -interpreter=mi' should start the latest stable version, not
the latest version.  so if mi5 is stable and mi6 is unstable,
you'd have to say '-interpreter=mi6' to get the unstable version.

>    * says *nothing* about other versions that GDB supports

so print a list of versions.  this was already mentioned a couple
times.  there's no difference between running
    gdb -print-all-mi-versions
and running
    printf "info mi\nquit\n" | gdb -interpreter=mi

>    * gives no way for a front end to determine if it is using a
>      deprecated protocol.

this can be information in the list of versions.

>    * puts the bug finding of the MI protocol on the users, even though the 
>      protocols have been deprecated.

this is a problem everywhere and difficult to solve in general.
the first thought most people will have is "maybe it's fixed in a
newer version", and it's pretty easy to try a newer gdb version.
also, assume that anyone who knows how to use gdb also knows how
to search for an answer with Google and/or file a bug report.

Bob, I think this discussion would have been finished a long time
ago if you had just submitted a patch for gdb that did what you
wanted.  the first attempt might get some discussion and need
some modification before getting accepted, but that usually
doesn't take very long.

most of this argument has been about people saying basically,
"well, if I were doing it, I'd do it differently", which is just
quibbling for an issue as simple as this.  gdb, like most
volunteer projects, never has enough manpower to do everything
that "should" be done.  development is always about evolution in
response to demand.

the project is the sum of what people care about, and you care
the most about this issue.  any patch you submit has an automatic
advantage over everyone else's lack of interest in working on
this issue, and the gdb people are usually happy to incorporate
anything that isn't egregiously bad.
--

Re: probing GDB for MI versions

[Eli Zaretskii]

> Date: Tue, 19 Oct 2004 09:28:24 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> I believe that printing the latest stable version of MI is plenty
> adequate.

I agree.

Re: probing GDB for MI versions

[Eli Zaretskii]

> From: Felix Lee <felix.1@canids.net>
> Date: Tue, 19 Oct 2004 12:28:26 -0700
> 
> 'gdb -interpreter=mi' should start the latest stable version, not
> the latest version.

A good idea, IMHO.

> >    * gives no way for a front end to determine if it is using a
> >      deprecated protocol.
> 
> this can be information in the list of versions.

Indeed.

Re: probing GDB for MI versions

[Bob Rossi]

On Tue, Oct 19, 2004 at 12:28:26PM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> >    * *requires* a restart
> 
> there's no difference between running
>     gdb -print-stable-mi-version
> and running
>     printf "quit\n" | gdb -interpreter=mi

Yes, I understand, that's why it is obvious and intuitive to have a
negotiation. This requires little code and is clearly an algorithmic way
for the front end to get it correct each time.

> >    * requires printing the latest stable version even though GDB may not be 
> >      even speaking that version
> 
> 'gdb -interpreter=mi' should start the latest stable version, not
> the latest version.  so if mi5 is stable and mi6 is unstable,
> you'd have to say '-interpreter=mi6' to get the unstable version.

Is this a fact? That is good news and a misunderstanding on my part!

> >    * says *nothing* about other versions that GDB supports
> 
> so print a list of versions.  this was already mentioned a couple
> times.  there's no difference between running
>     gdb -print-all-mi-versions
> and running
>     printf "info mi\nquit\n" | gdb -interpreter=mi
> 
> >    * gives no way for a front end to determine if it is using a
> >      deprecated protocol.
> 
> this can be information in the list of versions.

OK, that would be good.

> >    * puts the bug finding of the MI protocol on the users, even though the 
> >      protocols have been deprecated.
> 
> this is a problem everywhere and difficult to solve in general.
> the first thought most people will have is "maybe it's fixed in a
> newer version", and it's pretty easy to try a newer gdb version.
> also, assume that anyone who knows how to use gdb also knows how
> to search for an answer with Google and/or file a bug report.
> 
> Bob, I think this discussion would have been finished a long time
> ago if you had just submitted a patch for gdb that did what you
> wanted.  the first attempt might get some discussion and need
> some modification before getting accepted, but that usually
> doesn't take very long.
> 
> most of this argument has been about people saying basically,
> "well, if I were doing it, I'd do it differently", which is just
> quibbling for an issue as simple as this.  gdb, like most
> volunteer projects, never has enough manpower to do everything
> that "should" be done.  development is always about evolution in
> response to demand.
> 
> the project is the sum of what people care about, and you care
> the most about this issue.  any patch you submit has an automatic
> advantage over everyone else's lack of interest in working on
> this issue, and the gdb people are usually happy to incorporate
> anything that isn't egregiously bad.
> --

Thanks Felix, I'll come up with something and let you guys tear it
apart! I just didn't want to start something and waste my time on it.

Thanks,
Bob Rossi

backtrace changes current source location

[Felix Lee]

after doing a backtrace, the current source location is set to
the last frame in the backtrace, which is often main().  this
doesn't seem like useful behavior.  I think backtrace shouldn't
change the current source location at all, but it's been that way
since gdb 5.3.

this is when the change happened:
    http://sources.redhat.com/ml/gdb-patches/2002-08/msg00358.html
any time frame info gets printed, the current source location is
set to that frame, which seems reasonable to me, but it causes
this awkward backtrace behavior.

maybe backtraces should be considered a special case, and
stack.c:backtrace_command_1 should save/restore the current
source location around the call to print_frame_info?
--

Re: backtrace changes current source location

[Daniel Jacobowitz]

On Tue, Oct 26, 2004 at 12:51:15AM -0700, Felix Lee wrote:
> after doing a backtrace, the current source location is set to
> the last frame in the backtrace, which is often main().  this
> doesn't seem like useful behavior.  I think backtrace shouldn't
> change the current source location at all, but it's been that way
> since gdb 5.3.
> 
> this is when the change happened:
>     http://sources.redhat.com/ml/gdb-patches/2002-08/msg00358.html
> any time frame info gets printed, the current source location is
> set to that frame, which seems reasonable to me, but it causes
> this awkward backtrace behavior.
> 
> maybe backtraces should be considered a special case, and
> stack.c:backtrace_command_1 should save/restore the current
> source location around the call to print_frame_info?

I've been meaning to fix this since 6.0... I think your suggestion is
reasonable; do you want to try it?

-- 
Daniel Jacobowitz

Re: backtrace changes current source location

[Felix Lee]

Daniel Jacobowitz <drow@false.org>:
> I've been meaning to fix this since 6.0... I think your suggestion is
> reasonable; do you want to try it?

sure.  sending to gdb-patches.
--

Re: probing GDB for MI versions

[Bob Rossi]

> Bob, I think this discussion would have been finished a long time
> ago if you had just submitted a patch for gdb that did what you
> wanted.  the first attempt might get some discussion and need
> some modification before getting accepted, but that usually
> doesn't take very long.

I submitted a patch that allows GDB to handshake with the front end. It
is here http://sources.redhat.com/ml/gdb-patches/2004-11/msg00125.html

Basically, when started with -i=mi, GDB outputs all the tested versions
that it supports. If there is only 1, which has been the case so far,
GDB prints it and starts like normal in that mode. If there is more than
one, GDB waits for the front end to select a version and then will
continue with the version selected. The output looks like below,

   $ gdb -i=mi
   handshake={stable_protocols={mi2}}
   ~"GNU gdb 6.3.50_2004-11-08-cvs\n"
   ...

Any suggestions?

Thanks,
Bob Rossi

Re: HP gdb/wdb sources available

[Daniel Jacobowitz]

On Mon, Aug 29, 2005 at 05:02:46PM -0700, James E Wilson wrote:
> On Mon, 2005-08-29 at 13:30, Steve Ellcey wrote:
> > The purpose of this delivery is to assign the copyright of any HP
> > generated changes in these files to FSF so that non-HP folks can take
> > any of the changes that HP made and incorporate them into the FSF gdb
> > sources without worrying about HP copyright ownership.  I have a
> > copyright assignment on file with FSF.
> 
> This doesn't seem to make much sense.
> 
> Simply placing the files on an FSF machine does not constitute a
> copyright assignment.  A copyright assignment requires a piece of paper
> with appropriate language approved by the FSF and signed by a VP or
> higher at HP that covers the code in question.  (And by the way, this
> isn't an FSF machine, so by placing something here, you haven't actually
> given it to the FSF.)
> 
> Also, your copyright assignment only covers code that you wrote
> yourself.  If you give code to the FSF, that does not cause the code to
> be covered by your copyright assignment.  We need a copyright assignment
> from the original author of the code.  If HP has a corporate assignment,
> then that would be sufficient.  Otherwise, we need personal assignments
> from everyone that helped write the code, along with corporate
> disclaimers for each person.  If you haven't been keeping records of who
> wrote which piece of code (such as FSF style ChangeLog entries), then
> only a corporate assignment will do.

I am inclined to agree with Jim's concerns about copyright assignments.

I took a look at copyright.list, and could not figure out whether this
was covered by HP's prior assignments; they have a number of
assignments covering GDB but I don't think any of them were "and future
changes".

Jim, as for the actual act of putting it on sourceware.org, my
understanding is that it acts as a public release in tandem with the
announcement.  We've done this for large GDB drops from other companies
(ACT, Apple) in the past and gotten consensus that it was the right way
to go.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: HP gdb/wdb sources available

[Paul Hilfinger]

 > > Simply placing the files on an FSF machine does not constitute a
 > > copyright assignment.  A copyright assignment requires a piece of paper
 > > with appropriate language approved by the FSF and signed by a VP or
 > > higher at HP that covers the code in question.  (And by the way, this
 > > isn't an FSF machine, so by placing something here, you haven't actually
 > > given it to the FSF.)
 > > 
 > > Also, your copyright assignment only covers code that you wrote
 > > yourself.  If you give code to the FSF, that does not cause the code to
 > > be covered by your copyright assignment.  We need a copyright assignment
 > > from the original author of the code.  If HP has a corporate assignment,
 > > then that would be sufficient.  Otherwise, we need personal assignments
 > > from everyone that helped write the code, along with corporate
 > > disclaimers for each person.  If you haven't been keeping records of who
 > > wrote which piece of code (such as FSF style ChangeLog entries), then
 > > only a corporate assignment will do.
 > 
 > I am inclined to agree with Jim's concerns about copyright assignments.
 > 
 > I took a look at copyright.list, and could not figure out whether this
 > was covered by HP's prior assignments; they have a number of
 > assignments covering GDB but I don't think any of them were "and future
 > changes".

AdaCore and HP had a little conference-call discussion on this matter
(which included some of HP's legal staff) some weeks ago, leading to
this particular course of action.  HP should really comment on this to
confirm my impression, of course, since I cannot speak for them.

Basically, my recollection is that HP's understanding of their
assignment was that certain specified individuals within HP are
authorized to select and contribute parts of HP's source code for
Binutils, GCC, Glibc, and GDB and that these contributions are defined
to be what is assigned by HP to the FSF.  Ted Teah at the FSF seemed
to agree with this assessment when I mailed him about it.  So, yes,
while merely placing files on the FSF site (or checking them in, for
that matter) does not normally in itself constitute copyright
assignment, it does by this agreement.

Paul Hilfinger

Laziness

[David Lecomber]

Hi Folks,

Take a simple code with a big array...

#include <stdio.h>
int main()
{
  double x[1000][1000];
  printf("hello mum");
}

and ask gdb to "set print elements 1", then break at the printf, and say
"output x".  

It takes a while..  (not as much as it used to on Linux thanks to
the /proc memory reading recently committed) but on other platforms it
literally sucks.

The busy bit of the stack is here:

#6  0x0807f37b in target_read_memory (memaddr=3207201336,
myaddr=0xb5e49048 "", len=8000000) at target.c:1000
#7  0x08084a5a in read_memory (memaddr=3207201336, myaddr=0xb5e49048 "",
len=8000000) at corefile.c:239
#8  0x080e2509 in value_fetch_lazy (val=0xb5e49008) at valops.c:515
#9  0x080dc4fb in value_contents_all (value=0xb5e49008) at value.c:331
#10 0x08167551 in c_value_print (val=0xb5e49008, stream=0x91ea940,
format=0, pretty=Val_pretty_default)
    at c-valprint.c:596
#11 0x080eb0f4 in print_formatted (val=0xb5e49008, format=0, size=0,
stream=0x91ea940) at .././gdb/printcmd.c:335
#12 0x080eb776 in output_command (exp=0x91ea9a7 "x", from_tty=1)
at .././gdb/printcmd.c:985


Should we really really be reading all that memory, just to print the
first element?  I mean, not only is that slow, but it imposes a memory
overhead in the GDB too!

Should we be using a better method?

Cheers
David

-- 
David Lecomber <david@lecomber.net>

Re: Laziness

[Daniel Jacobowitz]

On Mon, Oct 10, 2005 at 10:04:09PM +0100, David Lecomber wrote:
> Hi Folks,
> 
> Take a simple code with a big array...
> 
> #include <stdio.h>
> int main()
> {
>   double x[1000][1000];
>   printf("hello mum");
> }
> 
> and ask gdb to "set print elements 1", then break at the printf, and say
> "output x".  

This is an inherent problem with the implementation of "set print
elements".  It prints only one _visible_ element, possibly with a
<repeats %u times> marker.  Search for that in valprint.c to see how
this works.

Perhaps we should redefine set print elements to only print anything
pertaining to the original number of elements.

> Should we really really be reading all that memory, just to print the
> first element?  I mean, not only is that slow, but it imposes a memory
> overhead in the GDB too!

Not really, for the latter complaint; we discard them as they're read
in.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Laziness

[David Lecomber]

> Perhaps we should redefine set print elements to only print anything
> pertaining to the original number of elements.

That's a fine idea!

> > Should we really really be reading all that memory, just to print the
> > first element?  I mean, not only is that slow, but it imposes a memory
> > overhead in the GDB too!
> 
> Not really, for the latter complaint; we discard them as they're read
> in.

Well, after they're read in, right? -- so that at peak it could be as
much as the memory of the actual array.  Not much of a problem for a
small code, but imagine some vast numerical code where an array is more
than half the actual available memory on the system - then GDB would
fail..  These codes really do exist.

Cheers
David

Re: Laziness

[Daniel Jacobowitz]

On Mon, Oct 10, 2005 at 10:22:23PM +0100, David Lecomber wrote:
> > > Should we really really be reading all that memory, just to print the
> > > first element?  I mean, not only is that slow, but it imposes a memory
> > > overhead in the GDB too!
> > 
> > Not really, for the latter complaint; we discard them as they're read
> > in.
> 
> Well, after they're read in, right? -- so that at peak it could be as
> much as the memory of the actual array.

No, as they're read in, one at a time, and compared to the previous
element.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Laziness

[David Lecomber]

On Mon, 2005-10-10 at 17:09 -0400, Daniel Jacobowitz wrote:

> 
> No, as they're read in, one at a time, and compared to the previous
> element.

Err, but I don't think they are.  I should've included the top of my
stack:

#1  0x00b3cb1a in ptrace () from /lib/libc.so.6
#2  0x0809512a in child_xfer_memory (memaddr=3207201336,
myaddr=0xb5e49048 "", len=8000000, write=0, attrib=0x0,
    target=0x8299460) at infptrace.c:437
#3  0x08095766 in child_xfer_partial (ops=0x8299460,
object=TARGET_OBJECT_MEMORY, annex=0x0,
    readbuf=0xb5e49048 "", writebuf=0x0, offset=The value of variable
'offset' is distributed across several
locations, and GDB cannot access its value.

) at inftarg.c:541
#4  0x0807eaa7 in target_xfer_partial (ops=0x8299460,
object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0xb5e49048,
    writebuf=0x0, offset=3207201336, len=The value of variable 'len' is
distributed across several
locations, and GDB cannot access its value.

) at target.c:863
#5  0x0807ec9f in xfer_using_stratum (object=TARGET_OBJECT_MEMORY,
annex=0x0, offset=3207201336, len=The value of variable 'len' is
distributed across several
locations, and GDB cannot access its value.

)
    at target.c:950
#6  0x0807f37b in target_read_memory (memaddr=3207201336,
myaddr=0xb5e49048 "", len=8000000) at target.c:1000
#7  0x08084a5a in read_memory (memaddr=3207201336, myaddr=0xb5e49048 "",
len=8000000) at corefile.c:239
#8  0x080e2509 in value_fetch_lazy (val=0xb5e49008) at valops.c:515
#9  0x080dc4fb in value_contents_all (value=0xb5e49008) at value.c:331
#10 0x08167551 in c_value_print (val=0xb5e49008, stream=0x91ea940,
format=0, pretty=Val_pretty_default)
    at c-valprint.c:596
#11 0x080eb0f4 in print_formatted (val=0xb5e49008, format=0, size=0,
stream=0x91ea940) at .././gdb/printcmd.c:335
#12 0x080eb776 in output_command (exp=0x91ea9a7 "x", from_tty=1)
at .././gdb/printcmd.c:985


That value_contents_all and massive read is happening a good few seconds
before we start doing the repeated elements comparison in
val_print_array_elements..


-- 
David Lecomber <david@lecomber.net>

Re: Laziness

[Daniel Jacobowitz]

On Mon, Oct 10, 2005 at 10:42:18PM +0100, David Lecomber wrote:
> That value_contents_all and massive read is happening a good few seconds
> before we start doing the repeated elements comparison in
> val_print_array_elements..

Then that's a different issue: gdb must just not support reading array
elements lazily... that will take more work to fix.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Laziness

[Paul Hilfinger]

> On Mon, Oct 10, 2005 at 10:42:18PM +0100, David Lecomber wrote:
> > That value_contents_all and massive read is happening a good few seconds
> > before we start doing the repeated elements comparison in
> > val_print_array_elements..
> 
> Then that's a different issue: gdb must just not support reading array
> elements lazily... that will take more work to fix.

That's right.  For Ada, it's been a recurring problem, possibly 
because Ada allows one to explicitly describe arrays whose size is
data-dependent.  So far we (AdaCore) has kludged around the resulting
performance problems in GDB in piecemeal fashion.  Perhaps this would
be a good time to consider more elegant and general approaches, if
they will find an audience outside Ada.

Of course, one can do this "by hand" (or by hand-crafted user-defined
command) with explicit pointer hacking, but perhaps we might seek a 
more user-friendly solution.

An obvious approach is to re-do the struct value API to further
lazify (sedate?) it.  Currently, values are fetched when needed, but

   a. GDB pre-allocates space for the whole eventual value, however huge,
   and

   b. When the value is delazified, GDB fetches the entire object.

With some enhancements to the struct value API and better enforcement
of its proper use, we could introduce a scheme that 

   a. Lazily allocated memory, as well as lazily fetching.

   b. Allowed for lazily slicing out subcomponents of a composite 
      value without GDB memory allocation for the target data.

On a separate but related note, I also envision a kind of "struct
value iterator" that allows one to sequence through a composite object
with a single struct value object, avoiding even the creation of new
struct values.  Such a mechanism could replace what the print routines
use now, which is basically a method of fetching target memory given
an address and type that is completely independent of the the struct
value mechanism.  There would be no functional improvement, but I
imagine we could clean things up a bit.

If any of this elicits interest, we might be persuaded to do the work.

Paul Hilfinger
AdaCore consultant

HP gdb/wdb sources available

[Steve Ellcey]

The HP gdb sources have been put on sourceware.org in
 ~ftp/pub/gdb/contrib/hp/wdb-20050829.tar.gz.  These are the same
sources HP makes available at http://www.hp.com/go/gdb (except it does
not include the Judy subdirectory).  Judy (a dynamic array package) is
already released under the LGPL at sourceforge.

The purpose of this delivery is to assign the copyright of any HP
generated changes in these files to FSF so that non-HP folks can take
any of the changes that HP made and incorporate them into the FSF gdb
sources without worrying about HP copyright ownership.  I have a
copyright assignment on file with FSF.

Steve Ellcey
sje@cup.hp.com