Re: starting gdb/mi from FE

[Bob Rossi <bob_rossi at cox dot net>]

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