starting gdb/mi from FE

starting gdb/mi from FE

[Bob Rossi]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

Hi,

I have an issue that will eventually come up in regards to starting GDB
from a front end. Choosing the correct interpreter that GDB supports
could be potentially non trivial, requiring several starts of GDB.
Currently, for each version of mi that the FE supports, it will have to
start GDB to see if it supports that version of the protocol. As the
list of MI protocol versions get's longer, this action get's longer and
longer. It would be good to solve this problem as early as possible for
obvious reasons.

Attached below is a patch that modified GDB so that it can accept the -i
flag as a comma sepearated list like shown below:

$ ./gdb/gdb -q -i=mi ./main
~"Using host libthread_db library \"/lib/tls/i686/cmov/libthread_db.so.1\".\n"
(gdb)

$ ./gdb/gdb -q -i=mi4,mi3 ./main
mi_protocol_version=mi3
~"Using host libthread_db library \"/lib/tls/i686/cmov/libthread_db.so.1\".\n"
(gdb)

This will allow the FE to start GDB 1 time and to determine which
version of the protocol GDB was compatible with. If you have multiple
interpreter choices on the -i switch, then GDB will output the first
line it writes as
    mi_protocol_version=miN
where miN will be the version GDB is going to communicate with.

This change is backwards compatible because users were not able in the 
past to have a comma separated list in the -i flag.

How does this look?

Thanks,
Bob Rossi

[-- Attachment #2: mi_protocol_ver.diff --]
[-- Type: text/plain, Size: 2098 bytes --]

Index: gdb/interps.c
===================================================================
RCS file: /cvs/src/src/gdb/interps.c,v
retrieving revision 1.16
diff -u -r1.16 interps.c
--- gdb/interps.c	17 Dec 2005 22:34:01 -0000	1.16
+++ gdb/interps.c	4 Jun 2006 23:54:14 -0000
@@ -216,16 +216,28 @@
 interp_lookup (const char *name)
 {
   struct interp *interp;
+  char *nname = xstrdup (name);
+  char *token = strtok (nname, ",");
 
-  if (name == NULL || strlen (name) == 0)
-    return NULL;
-
-  for (interp = interp_list; interp != NULL; interp = interp->next)
+  while (token)
     {
-      if (strcmp (interp->name, name) == 0)
-	return interp;
+      if (token == NULL || strlen (token) == 0)
+	return NULL;
+
+      for (interp = interp_list; interp != NULL; interp = interp->next)
+	{
+	  if (strcmp (interp->name, token) == 0)
+	  {
+	    xfree (nname);
+	    nname = NULL;
+	    return interp;
+	  }
+	}
+      token = strtok (NULL, ",");
     }
 
+  xfree (nname);
+  nname = NULL;
   return NULL;
 }
 
Index: gdb/main.c
===================================================================
RCS file: /cvs/src/src/gdb/main.c,v
retrieving revision 1.58
diff -u -r1.58 main.c
--- gdb/main.c	21 Feb 2006 19:46:48 -0000	1.58
+++ gdb/main.c	4 Jun 2006 23:54:15 -0000
@@ -598,6 +598,7 @@
 
   {
     /* Find it.  */
+    int multiple_interps = (strchr (interpreter_p, ',') != 0);
     struct interp *interp = interp_lookup (interpreter_p);
     if (interp == NULL)
       error (_("Interpreter `%s' unrecognized"), interpreter_p);
@@ -609,6 +610,17 @@
                             interpreter_p);
         exit (1);
       }
+
+    /* Print the mi version chosen by GDB if the user supplied multiple
+       options.  Note that the interp_set call above replaces interpreter_p 
+       with the value of the chosen interpreter.  */
+    if (multiple_interps)
+    {
+      struct ui_file *raw_stdout = stdio_fileopen (stdout);
+
+      fprintf_unfiltered (raw_stdout, "mi_protocol_version=%s\n", interpreter_p);
+    }
+
   }
 
   /* FIXME: cagney/2003-02-03: The big hack (part 2 of 2) that lets

Re: starting gdb/mi from FE

[Eli Zaretskii]

> Date: Mon, 5 Jun 2006 09:45:17 -0400
> From: Bob Rossi <bob_rossi@cox.net>
> 
> $ ./gdb/gdb -q -i=mi4,mi3 ./main

Multiple values separated by a comma is not how GNU programs accept
multiple values for the same option.  -i=mi4 -i=mi3 is more like it.

In any case, any change in the command-line options should be
accompanied by a suitable change to the user manual.

Thanks.

Re: starting gdb/mi from FE

[Bob Rossi]

On Mon, Jun 05, 2006 at 10:56:30PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 5 Jun 2006 09:45:17 -0400
> > From: Bob Rossi <bob_rossi@cox.net>
> > 
> > $ ./gdb/gdb -q -i=mi4,mi3 ./main
> 
> Multiple values separated by a comma is not how GNU programs accept
> multiple values for the same option.  -i=mi4 -i=mi3 is more like it.

OK, so should I make this change then and repost?

> In any case, any change in the command-line options should be
> accompanied by a suitable change to the user manual.

Yes, of course, I'm just seeing if this change would be acceptable.

Bob Rossi

Re: starting gdb/mi from FE

[Daniel Jacobowitz]

On Mon, Jun 05, 2006 at 09:45:17AM -0400, Bob Rossi wrote:
> This will allow the FE to start GDB 1 time and to determine which
> version of the protocol GDB was compatible with. If you have multiple
> interpreter choices on the -i switch, then GDB will output the first
> line it writes as
>     mi_protocol_version=miN
> where miN will be the version GDB is going to communicate with.
> 
> This change is backwards compatible because users were not able in the 
> past to have a comma separated list in the -i flag.
> 
> How does this look?

We've discussed this at least twice in the past, haven't we?  How about
a pointer to those past conversations; did they reach a conclusion, or
not - and if they did, was it this one?

-- 
Daniel Jacobowitz
CodeSourcery

Re: starting gdb/mi from FE

[Eli Zaretskii]

> Date: Mon, 5 Jun 2006 15:58:23 -0400
> From: Bob Rossi <bob_rossi@cox.net>
> Cc: gdb-patches@sources.redhat.com
> 
> OK, so should I make this change then and repost?

Let's first recap on the past discussions and take it from there.

Re: starting gdb/mi from FE

[Bob Rossi]

On Mon, Jun 05, 2006 at 03:59:30PM -0400, Daniel Jacobowitz wrote:
> On Mon, Jun 05, 2006 at 09:45:17AM -0400, Bob Rossi wrote:
> > This will allow the FE to start GDB 1 time and to determine which
> > version of the protocol GDB was compatible with. If you have multiple
> > interpreter choices on the -i switch, then GDB will output the first
> > line it writes as
> >     mi_protocol_version=miN
> > where miN will be the version GDB is going to communicate with.
> > 
> > This change is backwards compatible because users were not able in the 
> > past to have a comma separated list in the -i flag.
> > 
> > How does this look?
> 
> We've discussed this at least twice in the past, haven't we?  How about
> a pointer to those past conversations; did they reach a conclusion, or
> not - and if they did, was it this one?

Yes, we have. At least once encouraged by me. I think this time I have
an elegant solution which is much simpler than solutions from the past.

The key to simplicity is to realize that any front end knows a certain 
amount of MI protocols. It's goal is to sink with GDB using the highest
command protocol. So, passing them all in and getting a response is the
easiest way to go.

In the past I implemented a solution where the FE would pass in -i=mi
and GDB would respond with all the versions it supports and then would
wait for a response from the front end giving GDB the version to choose.
This solution also has a MI Handshaking description which front ends
could implement. This patch was never reviewed, probably because it
was overly complicated. This was the start of a very long thread
  http://sourceware.org/ml/gdb/2004-10/msg00027.html

Bob Rossi

Re: starting gdb/mi from FE

[Daniel Jacobowitz]

On Mon, Jun 05, 2006 at 10:56:30PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 5 Jun 2006 09:45:17 -0400
> > From: Bob Rossi <bob_rossi@cox.net>
> > 
> > $ ./gdb/gdb -q -i=mi4,mi3 ./main
> 
> Multiple values separated by a comma is not how GNU programs accept
> multiple values for the same option.  -i=mi4 -i=mi3 is more like it.

Is it?  I couldn't find anything about this in e.g. the coding
standards.

I find -i=mi4,mi3 more intuitive here; I'd interpret -i=mi4 -i=mi3 as
either "use both" or "use the last one on the command line", but
-i=mi4,mi3 as either "use both" or "use the first one which works".
I think the "use the last one" behavior is fairly common; otherwise
there'd be no way to invoke a command specified as "gdb -i=mi2" in mi1
mode without sedding the user-specified command looking for -i options.

Of course I don't have a strong opinion on this.  Just musing; feel
free to ignore.

-- 
Daniel Jacobowitz
CodeSourcery

Re: starting gdb/mi from FE

[Bob Rossi]

On Mon, Jun 05, 2006 at 05:25:32PM -0400, Daniel Jacobowitz wrote:
> On Mon, Jun 05, 2006 at 10:56:30PM +0300, Eli Zaretskii wrote:
> > > Date: Mon, 5 Jun 2006 09:45:17 -0400
> > > From: Bob Rossi <bob_rossi@cox.net>
> > > 
> > > $ ./gdb/gdb -q -i=mi4,mi3 ./main
> > 
> > Multiple values separated by a comma is not how GNU programs accept
> > multiple values for the same option.  -i=mi4 -i=mi3 is more like it.
> 
> Is it?  I couldn't find anything about this in e.g. the coding
> standards.
> 
> I find -i=mi4,mi3 more intuitive here; I'd interpret -i=mi4 -i=mi3 as
> either "use both" or "use the last one on the command line", but
> -i=mi4,mi3 as either "use both" or "use the first one which works".
> I think the "use the last one" behavior is fairly common; otherwise
> there'd be no way to invoke a command specified as "gdb -i=mi2" in mi1
> mode without sedding the user-specified command looking for -i options.
> 
> Of course I don't have a strong opinion on this.  Just musing; feel
> free to ignore.

I agree with you, which is obviously why I wrote it that way. I'm
completely ignorant to GNU standards though. Most of what I know I've
learned here from you kind people.

Bob Rossi

Re: starting gdb/mi from FE

[Eli Zaretskii]

> Date: Mon, 5 Jun 2006 17:25:32 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Mon, Jun 05, 2006 at 10:56:30PM +0300, Eli Zaretskii wrote:
> > > Date: Mon, 5 Jun 2006 09:45:17 -0400
> > > From: Bob Rossi <bob_rossi@cox.net>
> > > 
> > > $ ./gdb/gdb -q -i=mi4,mi3 ./main
> > 
> > Multiple values separated by a comma is not how GNU programs accept
> > multiple values for the same option.  -i=mi4 -i=mi3 is more like it.
> 
> Is it?  I couldn't find anything about this in e.g. the coding
> standards.

It isn't a codified rule; I just couldn't recall any program that does
this.  But now I recalled one: gcc (with the -Wl linker options), so I
guess my gut feeling was wrong.  (Commas are used by many Windows
programs, and I always disliked that; but that's me.)

Re: starting gdb/mi from FE

[Jim Ingham]

Stuff like this doesn't currently work:

(top-gdb) interpreter-exec console "set interpreter mi1"
-exec-run
readline: readline_callback_read_char() called with no handler!
Abort

I haven't looked into how hard it would be to get this to work.  I'd  
have to go dig back through my mail to see what else they were worried  
about, it was a couple of years ago now.

Jim


On Jun 6, 2006, at 10:29 AM, Daniel Jacobowitz wrote:

> On Tue, Jun 06, 2006 at 08:39:21AM -0700, Jim Ingham wrote:
>> part was explicitly rejected.  IIRC the argument at the time was that
>> you could manage to do nested calls to set interpreter, and it was
>> hard to make that work.  This didn't so much bother me - people who
>> taunt the software like that deserve what they get.  So I've
>
> As long as we either make it work, or make it error(), I'm happy...
> though I'd have expected it to work.
>
> -- 
> Daniel Jacobowitz
> CodeSourcery

Re: starting gdb/mi from FE

[Daniel Jacobowitz]

On Tue, Jun 06, 2006 at 08:39:21AM -0700, Jim Ingham wrote:
> part was explicitly rejected.  IIRC the argument at the time was that  
> you could manage to do nested calls to set interpreter, and it was  
> hard to make that work.  This didn't so much bother me - people who  
> taunt the software like that deserve what they get.  So I've  

As long as we either make it work, or make it error(), I'm happy...
though I'd have expected it to work.

-- 
Daniel Jacobowitz
CodeSourcery

Re: starting gdb/mi from FE

[Jim Ingham]

On Jun 5, 2006, at 7:02 PM, Nick Roberts wrote:

>> Nick, could you explain why the restart is a problem?  The time GDB
>> takes to reject an interpreter doesn't seem too bad.  I don't want to
>> optimize the wrong thing.
>
> It's just more complicated to handle and I can see no advantage.   
> With Emacs,
> compare M-x gdb and mistyping a CLI command to M-x gdb and giving  
> gdb an
> unrecognised option.
>
>> ...
>> I thought there already was a "set interp", but it seems I was
>> mistaken.
>
> I think Apple have such a command but have not ported it back to FSF  
> GDB

This is not relevant to the discussion, but just to get the history  
right...  "set interpreter" was part of the interpreter command that I  
did a while back.  When it was ported to FSF gdb (Keith, Andrew and  
Elena were the ones involved with this, IIRC)  the "set interpreter"  
part was explicitly rejected.  IIRC the argument at the time was that  
you could manage to do nested calls to set interpreter, and it was  
hard to make that work.  This didn't so much bother me - people who  
taunt the software like that deserve what they get.  So I've  
maintained it as a patch in our sources because having to run the  
whole session in mi mode when debugging mi commands is a RPITA.

Jim

Re: starting gdb/mi from FE

[Daniel Jacobowitz]

On Mon, Jun 05, 2006 at 09:56:21PM -0400, Bob Rossi wrote:
> > Would -interpreter-list and -interpreter-set do it for you?
> > 
> > I thought there already was a "set interp", but it seems I was
> > mistaken.
> 
> Well, I'm not sure. My initial guess is no. Nick, please check this part
> out also, especially in regards to your -mi-version command.
> 
> If GDB successfully starts with a -i=miN or just using the CLI and
> hoping to switch to MI, then GDB is allowed to execute an arbitrary
> number of commands before the FE can issue even a single command.
> At least, in the CLI mode this is true if the user has commands in
> .gdbinit.
> 
> I really can't afford to recieve a single MI output commadn before I
> determine what generated parser I am going to use. So, I'll be stuck
> starting GDB N times :(

To avoid .gdbinit, start gdb with -nx.  If you want, then source
.gdbinit or $HOME/.gdbinit yourself.  You'll have to duplicate the
search for gdbinit files, but it's not as if that's a big deal.

As for whether you can parse the response of -interpreter-list, I don't
think there's any point in planning for that sort of drastic change to
the protocol.  We're talking about selecting a version of MI; all
versions of MI are supposed to follow more or less the same formats.

-- 
Daniel Jacobowitz
CodeSourcery

Re: starting gdb/mi from FE

[Nick Roberts]

 > >  >                                                I think it's bad to
 > >  > provide functionality that only works with makeshift parsers.
 > > 
 > > I think we need to be practical and work within our limited resources.  If
 > > a corporate sponsor comes along then maybe we can consider such general
 > > principles.
 > 
 > I'm confused, the patch I provided is about 20 lines of code. If you are
 > talking about generating a parser, I've also done that with a 300 line
 > bison input file.  I think I'm misunderstanding you here.

Yes, but I don't think your patch will work.  My proposal is also simple
but, as you say, doesn't address all eventualities.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: starting gdb/mi from FE

[Bob Rossi]

On Tue, Jun 06, 2006 at 02:02:16PM +1200, Nick Roberts wrote:
>  > Nick, could you explain why the restart is a problem?  The time GDB
>  > takes to reject an interpreter doesn't seem too bad.  I don't want to
>  > optimize the wrong thing.
> 
> It's just more complicated to handle and I can see no advantage.  With Emacs,
> compare M-x gdb and mistyping a CLI command to M-x gdb and giving gdb an
> unrecognised option.

If Nick and I agree on nothing else, we agree here.

Bob Rossi

Re: starting gdb/mi from FE

[Nick Roberts]

 > Nick, could you explain why the restart is a problem?  The time GDB
 > takes to reject an interpreter doesn't seem too bad.  I don't want to
 > optimize the wrong thing.

It's just more complicated to handle and I can see no advantage.  With Emacs,
compare M-x gdb and mistyping a CLI command to M-x gdb and giving gdb an
unrecognised option.
 
 > ...
 > I thought there already was a "set interp", but it seems I was
 > mistaken.

I think Apple have such a command but have not ported it back to FSF GDB

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: starting gdb/mi from FE

[Bob Rossi]

On Tue, Jun 06, 2006 at 01:55:40PM +1200, Nick Roberts wrote:
> B> > > $This change is backwards compatible because users were not able in the 
>  > > > $past to have a comma separated list in the -i flag.
>  > > 
>  > > Backward compatible because it won't work with any version before GDB 6.5?
>  > 
>  > Backward compatible because FE's can use mi2 when they do mi2, and
>  > mi3,mi2 when they do more than mi2. I'm thinking no front end will ever
>  > support mi1 (correct me if I'm wrong). Therefore, if we do this now,
>  > it'll work for most FE's.
> 
> But it won't work for *released* versions of GDB.

Hmmm, I see your point. As soon as I support mi3, it won't work with
these old released GDB's anymore. In that case, I'll know that I have to
try start GDB with just mi2 on it's own. I don't see any other solution.

>  >...
>  > > Pre GDB 6.5 wouldn't really work in this case either, but
>  > > 
>  > >   (gdb)
>  > >   -mi-version
>  > >   ^error,msg="Undefined MI command: mi-version"
>  > >   (gdb)
>  > > 
>  > > wouldn't require restarting GDB, while:
>  > > 
>  > >   nickrob/21 gdb -i=mi2,mi1 myprog
>  > >   Interpreter `mi2,mi1' unrecognized
>  > >   nickrob/22
>  > > 
>  > > would.
>  > 
>  > That's not correct. Unless you will work with mi1. It will work with mi2
>  > on as described above. 
> 
> I don't see how, unless you plan to `recall' all released versions of GDB.
> 
>  >                        Also, the solution your provide is a chicken/egg 
>  > problem. If anyone ever changes the MI output syntax in a non backwards 
>  > compatible way, then I will not know which generated parser to use. If I
>  > don't know which generated parser to use, I can't possible call
>  > -mi-version and expect to parse the output.
> 
> If it changes from:
> 
> (gdb)
> -mi-version
> ^done,major="3",minor="1"
> (gdb)
> 
> your right, but I think this part of MI should be pretty constant.  I imagine
> MI level changes involving things like asynchronous operation, event
> notification etc.

This solution works if you can guarentee that the protocol will never
change. I don't care anything about the format of specific MI commands.

>  >                                                I think it's bad to provide
>  > functionality that only works with makeshift parsers.
> 
> I think we need to be practical and work within our limited resources.  If
> a corporate sponsor comes along then maybe we can consider such general
> principles.

I'm confused, the patch I provided is about 20 lines of code. If you are
talking about generating a parser, I've also done that with a 300 line
bison input file.  I think I'm misunderstanding you here.

Bob Rossi

Re: starting gdb/mi from FE

[Bob Rossi]

On Mon, Jun 05, 2006 at 09:20:02PM -0400, Daniel Jacobowitz wrote:
> On Tue, Jun 06, 2006 at 12:54:54PM +1200, Nick Roberts wrote:
> > I can't remember the previous outcome (I got lost with all the handshakes) but
> > I would prefer an MI command, -mi-version say, that the FE could use.  It
> > could have a major and minor part: the major number to refer to the default MI
> > level; and the minor to help identify small changes made within one level.  Of
> > course, we'd have to remember to update it, when appropriate.
> > 
> > Pre GDB 6.5 wouldn't really work in this case either, but
> > 
> >   (gdb)
> >   -mi-version
> >   ^error,msg="Undefined MI command: mi-version"
> >   (gdb)
> > 
> > wouldn't require restarting GDB, while:
> > 
> >   nickrob/21 gdb -i=mi2,mi1 myprog
> >   Interpreter `mi2,mi1' unrecognized
> >   nickrob/22
> > 
> > would.
> 
> Two items.
> 
> Nick, could you explain why the restart is a problem?  The time GDB
> takes to reject an interpreter doesn't seem too bad.  I don't want to
> optimize the wrong thing.

I would prefer not to restart GDB. I'm not so sure I agree with you that
the restart time is not a problem. I think it would be noticable on
older machines.

> Bob, since we last discussed this the interpreter commands have matured
> a bit.  There's even tab completion for the CLI interpreter-exec
> command; try "interpreter-exec <tab>" and you'll get a list.

Yes, I see that now. My patch was causing GDB to crash when doing that.
I'll have to look more closely at the patch.

> Would -interpreter-list and -interpreter-set do it for you?
> 
> I thought there already was a "set interp", but it seems I was
> mistaken.

Well, I'm not sure. My initial guess is no. Nick, please check this part
out also, especially in regards to your -mi-version command.

If GDB successfully starts with a -i=miN or just using the CLI and
hoping to switch to MI, then GDB is allowed to execute an arbitrary
number of commands before the FE can issue even a single command.
At least, in the CLI mode this is true if the user has commands in
.gdbinit.

I really can't afford to recieve a single MI output commadn before I
determine what generated parser I am going to use. So, I'll be stuck
starting GDB N times :(

Bob Rossi

Re: starting gdb/mi from FE

[Nick Roberts]

B> > > $This change is backwards compatible because users were not able in the 
 > > > $past to have a comma separated list in the -i flag.
 > > 
 > > Backward compatible because it won't work with any version before GDB 6.5?
 > 
 > Backward compatible because FE's can use mi2 when they do mi2, and
 > mi3,mi2 when they do more than mi2. I'm thinking no front end will ever
 > support mi1 (correct me if I'm wrong). Therefore, if we do this now,
 > it'll work for most FE's.

But it won't work for *released* versions of GDB.

 >...
 > > Pre GDB 6.5 wouldn't really work in this case either, but
 > > 
 > >   (gdb)
 > >   -mi-version
 > >   ^error,msg="Undefined MI command: mi-version"
 > >   (gdb)
 > > 
 > > wouldn't require restarting GDB, while:
 > > 
 > >   nickrob/21 gdb -i=mi2,mi1 myprog
 > >   Interpreter `mi2,mi1' unrecognized
 > >   nickrob/22
 > > 
 > > would.
 > 
 > That's not correct. Unless you will work with mi1. It will work with mi2
 > on as described above. 

I don't see how, unless you plan to `recall' all released versions of GDB.

 >                        Also, the solution your provide is a chicken/egg 
 > problem. If anyone ever changes the MI output syntax in a non backwards 
 > compatible way, then I will not know which generated parser to use. If I
 > don't know which generated parser to use, I can't possible call
 > -mi-version and expect to parse the output.

If it changes from:

(gdb)
-mi-version
^done,major="3",minor="1"
(gdb)

your right, but I think this part of MI should be pretty constant.  I imagine
MI level changes involving things like asynchronous operation, event
notification etc.

 >                                                I think it's bad to provide
 > functionality that only works with makeshift parsers.

I think we need to be practical and work within our limited resources.  If
a corporate sponsor comes along then maybe we can consider such general
principles.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: starting gdb/mi from FE

[Bob Rossi]

On Tue, Jun 06, 2006 at 12:54:54PM +1200, Nick Roberts wrote:
> > $ ./gdb/gdb -q -i=mi ./main
> > $~"Using host libthread_db library \"/lib/tls/i686/cmov/libthread_db.so.1\".\n"
> > $(gdb)
> 
> > $$ ./gdb/gdb -q -i=mi4,mi3 ./main
> > $mi_protocol_version=mi3
> > $~"Using host libthread_db library \"/lib/tls/i686/cmov/libthread_db.so.1\".\n"
> > $(gdb)
> 
> > $This will allow the FE to start GDB 1 time and to determine which
> > $version of the protocol GDB was compatible with. If you have multiple
> > $interpreter choices on the -i switch, then GDB will output the first
> > $line it writes as
> > $    mi_protocol_version=miN
> > $where miN will be the version GDB is going to communicate with.
> 
> > $This change is backwards compatible because users were not able in the 
> > $past to have a comma separated list in the -i flag.
> 
> Backward compatible because it won't work with any version before GDB 6.5?

Backward compatible because FE's can use mi2 when they do mi2, and
mi3,mi2 when they do more than mi2. I'm thinking no front end will ever
support mi1 (correct me if I'm wrong). Therefore, if we do this now,
it'll work for most FE's.

> > How does this look?
> 
> I can't remember the previous outcome (I got lost with all the handshakes) but
> I would prefer an MI command, -mi-version say, that the FE could use.  It
> could have a major and minor part: the major number to refer to the default MI
> level; and the minor to help identify small changes made within one level.  Of
> course, we'd have to remember to update it, when appropriate.

I would also not mind adding functionality like this on top of the
solution I'm requesting. I think they both have there place. See below
please.

> Pre GDB 6.5 wouldn't really work in this case either, but
> 
>   (gdb)
>   -mi-version
>   ^error,msg="Undefined MI command: mi-version"
>   (gdb)
> 
> wouldn't require restarting GDB, while:
> 
>   nickrob/21 gdb -i=mi2,mi1 myprog
>   Interpreter `mi2,mi1' unrecognized
>   nickrob/22
> 
> would.

That's not correct. Unless you will work with mi1. It will work with mi2
on as described above. Also, the solution your provide is a chicken/egg 
problem. If anyone ever changes the MI output syntax in a non backwards 
compatible way, then I will not know which generated parser to use. If I
don't know which generated parser to use, I can't possible call
-mi-version and expect to parse the output. I think it's bad to provide
functionality that only works with makeshift parsers.

Thanks,
Bob Rossi

Re: starting gdb/mi from FE

[Daniel Jacobowitz]

On Tue, Jun 06, 2006 at 12:54:54PM +1200, Nick Roberts wrote:
> I can't remember the previous outcome (I got lost with all the handshakes) but
> I would prefer an MI command, -mi-version say, that the FE could use.  It
> could have a major and minor part: the major number to refer to the default MI
> level; and the minor to help identify small changes made within one level.  Of
> course, we'd have to remember to update it, when appropriate.
> 
> Pre GDB 6.5 wouldn't really work in this case either, but
> 
>   (gdb)
>   -mi-version
>   ^error,msg="Undefined MI command: mi-version"
>   (gdb)
> 
> wouldn't require restarting GDB, while:
> 
>   nickrob/21 gdb -i=mi2,mi1 myprog
>   Interpreter `mi2,mi1' unrecognized
>   nickrob/22
> 
> would.

Two items.

Nick, could you explain why the restart is a problem?  The time GDB
takes to reject an interpreter doesn't seem too bad.  I don't want to
optimize the wrong thing.

Bob, since we last discussed this the interpreter commands have matured
a bit.  There's even tab completion for the CLI interpreter-exec
command; try "interpreter-exec <tab>" and you'll get a list.

Would -interpreter-list and -interpreter-set do it for you?

I thought there already was a "set interp", but it seems I was
mistaken.

-- 
Daniel Jacobowitz
CodeSourcery

Re: starting gdb/mi from FE

[Nick Roberts]

> $ ./gdb/gdb -q -i=mi ./main
> $~"Using host libthread_db library \"/lib/tls/i686/cmov/libthread_db.so.1\".\n"
> $(gdb)

> $$ ./gdb/gdb -q -i=mi4,mi3 ./main
> $mi_protocol_version=mi3
> $~"Using host libthread_db library \"/lib/tls/i686/cmov/libthread_db.so.1\".\n"
> $(gdb)

> $This will allow the FE to start GDB 1 time and to determine which
> $version of the protocol GDB was compatible with. If you have multiple
> $interpreter choices on the -i switch, then GDB will output the first
> $line it writes as
> $    mi_protocol_version=miN
> $where miN will be the version GDB is going to communicate with.

> $This change is backwards compatible because users were not able in the 
> $past to have a comma separated list in the -i flag.

Backward compatible because it won't work with any version before GDB 6.5?

> How does this look?

I can't remember the previous outcome (I got lost with all the handshakes) but
I would prefer an MI command, -mi-version say, that the FE could use.  It
could have a major and minor part: the major number to refer to the default MI
level; and the minor to help identify small changes made within one level.  Of
course, we'd have to remember to update it, when appropriate.

Pre GDB 6.5 wouldn't really work in this case either, but

  (gdb)
  -mi-version
  ^error,msg="Undefined MI command: mi-version"
  (gdb)

wouldn't require restarting GDB, while:

  nickrob/21 gdb -i=mi2,mi1 myprog
  Interpreter `mi2,mi1' unrecognized
  nickrob/22

would.

-- 
Nick                                           http://www.inet.net.nz/~nickrob