From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10138 invoked by alias); 2 May 2008 16:21:24 -0000 Received: (qmail 10125 invoked by uid 22791); 2 May 2008 16:21:23 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 May 2008 16:21:03 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id D2FFC983EC; Fri, 2 May 2008 16:21:01 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id A9866983D6; Fri, 2 May 2008 16:21:01 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1Jry0K-00020N-IO; Fri, 02 May 2008 12:21:00 -0400 Date: Fri, 02 May 2008 16:55:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Allow to enable run/stop notifications for function calls. Message-ID: <20080502162100.GA7412@caradoc.them.org> Mail-Followup-To: Vladimir Prus , gdb-patches@sources.redhat.com References: <200805011751.48573.vladimir@codesourcery.com> <20080502155907.GU29202@caradoc.them.org> <200805022002.56292.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200805022002.56292.vladimir@codesourcery.com> User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00102.txt.bz2 On Fri, May 02, 2008 at 08:02:55PM +0400, Vladimir Prus wrote: > > I'm still not convinced we need -enable-feature for anything that > > -gdb-set and -gdb-show can not handle. > > Is -gdb-show output specified in any way? Is it subject to i18n? Good point. For settings we expect MI clients to be interested in, we could use the ui_out mechanism to give them named fields. I think that will work fine. > > What do you think about bundling this sort of update into MI version > > 3? That cuts down on the number of possible knobs for output, which > > is IMO important. > > Well, this might be good idea, provided everybody concerned agree that > MI3 will be rapidly changing until futher notice and *no* compatibility > will be guaranteed until that point. I think that's fine, if we think we can settle it down by the next release. Or the first release to fully support non-stop and async, if that's not in time for the next release. At some point we will have to lock it in place, like we did for mi2. Existing clients should be using mi2. Some are probably just using -i=mi, but that's an easy bug to fix. -- Daniel Jacobowitz CodeSourcery