This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: starting gdb/mi from FE
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Bob Rossi <bob_rossi at cox dot net>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 6 Jun 2006 12:54:54 +1200
- Subject: Re: starting gdb/mi from FE
> $ ./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