From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14173 invoked by alias); 7 Oct 2004 19:28:33 -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 14164 invoked from network); 7 Oct 2004 19:28:32 -0000 Received: from unknown (HELO lakermmtao12.cox.net) (68.230.240.27) by sourceware.org with SMTP; 7 Oct 2004 19:28:32 -0000 Received: from white ([68.9.64.121]) by lakermmtao12.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041007192831.ZQKI10352.lakermmtao12.cox.net@white>; Thu, 7 Oct 2004 15:28:31 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFdwE-0003uA-00; Thu, 07 Oct 2004 15:28:30 -0400 Date: Thu, 07 Oct 2004 22:42:00 -0000 From: Bob Rossi To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: Bob's MI objective Message-ID: <20041007192830.GE14573@white> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <416451B0.3060306@gnu.org> <20041006212652.GB13271@white> <41647352.50603@gnu.org> <20041007163122.GC14573@white> <41659659.2030005@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41659659.2030005@gnu.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00232.txt.bz2 On Thu, Oct 07, 2004 at 03:17:45PM -0400, Andrew Cagney wrote: > >On Wed, Oct 06, 2004 at 06:36:02PM -0400, Andrew Cagney wrote: > > > >>>>> * I would like to know what GDB's policy is in regards to > >>>>supporting old > >>>>> MI protocols. ( I have received several opposing views on this ) > >> > >>> > >>>By "supported" you're expecting? I've stated what people developing GDB > >>>test, and given you a pretty clear hint as to the consequence. > > > > > >Understood, here is what I am hoping for at a minimum. > > > > * GDB supports at least 1 MI protocol for an official release. > > Supporting multiple MI protocols would be better for me, but > > not a requirement. If GDB could support multiple protocols it > > would improve the chances of a given front end working with a > > given GDB. > > But by "support" what do you mean - even a dictionary definition. GDB > includes at least one MI implementation, but that says nothing about how > well it is either implemented or supported. That's a good question. Well, by support I simply mean, GDB is officially saying that a particular MI protocol is implemented as it should be, that it is tested to make sure that it works to the best of the GDB developers knowledge and that it is safe to use by front ends. I am assuming that MI protocols in development ( right after a version bump, but before a major release ) is considered unsupported. By this I guess I mean that it should not be used by front ends until it is stable. Maybe a better word for "support" in this context is "stable". > > * GDB supports at least 1 MI protocol for a CVS snapshot. The > > development MI protocol is probably not suitable for front ends > > to work with, until it has stabilized and become official. So I am > > hoping that GDB supports the last officially supported MI protocol > > during it's development process, until the development protocol is > > ready to become stable. > > > > > >>>I was wondering more of what your project and its goals were. > > > > > >CGDB is the front end I am working on, that said, I am actually not > >doing all of the development of CGDB, just some of it. > > > >I am focusing more on libtgdb. This is basically a library that is > >capable of communicating with GDB with any interface that GDB supports. > > Why not instead help with libgdb, and the problem of being able to > directly link in the debugger? What implementation approach is libgdb taking? Does it expect the front end to link directly to it, so that a front end is tied to a particular version of GDB? I like the idea of a libgdb that is capable of communicating with any version of GDB that talks a valid MI protocol. This makes the library more flexible. I guess this is essentially the goal I am working towards with libtgdb. Bob Rossi