From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31801 invoked by alias); 6 Oct 2004 17:56:18 -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 31794 invoked from network); 6 Oct 2004 17:56:17 -0000 Received: from unknown (HELO epic.mail.pas.earthlink.net) (207.217.120.181) by sourceware.org with SMTP; 6 Oct 2004 17:56:17 -0000 Received: from ip216-26-76-19.dsl.du.teleport.com ([216.26.76.19] helo=stray.canids) by epic.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1CFG1R-00071M-00 for gdb@sources.redhat.com; Wed, 06 Oct 2004 10:56:17 -0700 Received: from stray.canids (localhost.localdomain [127.0.0.1]) by stray.canids (Postfix) with ESMTP id A2B22502AB6 for ; Wed, 6 Oct 2004 10:56:16 -0700 (PDT) From: Felix Lee To: gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's References: <20041003163918.GB7030@white> <01c4a9ce$Blat.v2.2.2$d01969a0@zahav.net.il> <20041004131906.GB8121@white> <200410041533.i94FXsPa014648@juw15.nfra.nl> <20041004155805.GF8121@white> <01c4aabb$Blat.v2.2.2$e64c8fc0@zahav.net.il> <20041005140736.GC13586@nevyn.them.org> <01c4ab8d$Blat.v2.2.2$93dba3c0@zahav.net.il> <20041006112703.GB11747@white> <20041006171253.58184502AB6@stray.canids> <20041006172045.GA8428@nevyn.them.org> In-Reply-To: <20041006172045.GA8428@nevyn.them.org> on Wed, 06 Oct 2004 13:20:45 EDT from Daniel Jacobowitz Date: Wed, 06 Oct 2004 17:58:00 -0000 Message-Id: <20041006175616.A2B22502AB6@stray.canids> X-SW-Source: 2004-10/txt/msg00165.txt.bz2 Daniel Jacobowitz : > Actually, I doubt GDB will continue to support old MI versions > indefinitely. It may be very hard. For instance, at some point we may > report multiple events to the front end at once (from different > threads); or multiple addresses associated with a breakpoint. Faking > an old interface will not be worth the trouble. > I expect there will be points at which front ends will have to be > updated to talk to a new GDB. right. if it's too hard to support an old MI, any front-end using the old MI will have the wrong model of interaction with gdb, so the front-end will need substantial work to talk to the new gdb no matter what, so that's not a problem either. --