From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7162 invoked by alias); 12 Jul 2004 17:28:09 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7153 invoked from network); 12 Jul 2004 17:28:08 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 12 Jul 2004 17:28:08 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id MAA18081 for ; Mon, 12 Jul 2004 12:47:30 -0400 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id NAA27544 for gdb@sources.redhat.com; Mon, 12 Jul 2004 13:28:06 -0400 Message-Id: <200407121728.NAA27544@smtp.ott.qnx.com> Subject: Re: MI level command To: bob@brasko.net (Bob Rossi) Date: Mon, 12 Jul 2004 17:38:00 -0000 From: "Alain Magloire" Cc: gdb@sources.redhat.com In-Reply-To: <20040709012815.GA4464@white> from "Bob Rossi" at Jul 08, 2004 09:28:15 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00110.txt.bz2 > > On Thu, Jul 08, 2004 at 07:33:17PM -0400, Alain Magloire wrote: > > Yellow > > > > > > Scenario: We want to know wich level of MI that we are currently working in. > > This can allow to adjust what MI command to use and how to parse them. > > > > Problems: No such command in MI and no GDB variable that we can test via -gdb-show. > > The version of gdb > > gdb --version > > show different things in different distributions, sometimes it is a number based on date > > etc ... > > > > So would a patch implementing > > > > -gdb-mi-level > > ^done,level=1 > > > > be a good thing ? > > I like this idea a lot. I will need it when I start getting more work > done on TGDB. However, there is another DRY problem. What functions act > which way for which level? > Agreed, it is a problem, I do not have any solutions. For example say thread-list-ids been crashing or misbehaved and the latest gdb fix the problems ... For front-ends how to know this is fix ? In theory the combination of version and the MI level should have done the trick. > Basically, should every front end understand that > -file-list-exec-source-files outputs just the files for level 1 but it > also outputs the libraries the files belong to in level2? > > One solution could be, for every MI function, we could generate a unique > key. For example, mi1-file-list-exec-source-files, > mi2-file-list-exec-source-files, ... > This key would tell the front end to use that particular parsing > function when checking the output of -file-list-exec-source-files. > > Is this to wacky? > It sounds like a lot of maintainance. How about for every release of gdb we bumb up a number ? Say MI level could return {0,1,2,..} and MI gdb version could return something else. So the unique key is for a release and all commands ... basically having taking the role of version. So why is "version" so mangle in gdb ?