Re: starting gdb/mi from FE

[Nick Roberts <nickrob at snap dot net dot nz>]

> $ ./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