From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17441 invoked by alias); 6 Jun 2006 00:55:46 -0000 Received: (qmail 17433 invoked by uid 22791); 6 Jun 2006 00:55:45 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Jun 2006 00:55:39 +0000 Received: from kahikatea.snap.net.nz (p202-124-112-224.snap.net.nz [202.124.112.224]) by viper.snap.net.nz (Postfix) with ESMTP id DC0C17589B5; Tue, 6 Jun 2006 12:55:36 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 07E681D3550; Tue, 6 Jun 2006 12:54:56 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17540.53854.931145.771214@kahikatea.snap.net.nz> Date: Tue, 06 Jun 2006 00:55:00 -0000 To: Bob Rossi Cc: gdb-patches@sources.redhat.com Subject: Re: starting gdb/mi from FE X-Mailer: VM 7.19 under Emacs 22.0.50.20 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00052.txt.bz2 > $ ./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