From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18558 invoked by alias); 7 May 2004 01:19:43 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18355 invoked from network); 7 May 2004 01:19:40 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 May 2004 01:19:40 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i471Jc0s021419 for ; Thu, 6 May 2004 21:19:39 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i46KAwv09698; Thu, 6 May 2004 16:10:59 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 77B662B9D; Thu, 6 May 2004 16:10:59 -0400 (EDT) Message-ID: <409A9BD3.6050803@gnu.org> Date: Fri, 07 May 2004 01:19:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Bob Rossi Cc: Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: [PATCH] implements MI "-file-list-exec-sections" (updated) References: <16530.51947.983270.138336@nick.uklinux.net> <20040501040929.GB17480@white> <16531.37648.806738.186535@nick.uklinux.net> <20040502132531.GB1487@white> In-Reply-To: <20040502132531.GB1487@white> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-05/txt/msg00172.txt.bz2 > On Sat, May 01, 2004 at 01:07:44PM +0100, Nick Roberts wrote: > >>> >>> > I think everyone agrees, changing the CLI would be the worst possible >>> > thing GDB could do. >>> >>> I'm not sure if thats true, I was just talking about timing. Its probably >>> not reasonable or even realistic to insist that CLI output never changes. > > > Well, over time, I can see the CLI changing. However, I would expect > that to happen after at least one open source project implemented the MI > front end (Don't say eclipse, they use a hybrid approach) and the MI > API was considered stable and capable of doing everything that could > be done from the CLI. Regardless of MI, the CLI is going to evolve. This is because the current implementation is limiting GDB's functionality. A few simple examples: - signal backtraces. They currently look something like: 0x1234 in foo 0x456 in bar but are about to be changed to: 0x1234 in foo 0x785 in 0x456 in bar This comes hand-in-hand with the raised expectation that operations such as "stepi"ing through a trampoline work (previously it was luck, typically bad :-). For the user this is all good, but I bet there's a CLI parsing gui out there that breaks - oops. - N:M breakpoints Again, the user will easily adapt. Andrew