From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27134 invoked by alias); 14 Nov 2007 19:18:21 -0000 Received: (qmail 27126 invoked by uid 22791); 14 Nov 2007 19:18:19 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Nov 2007 19:18:16 +0000 Received: from kahikatea.snap.net.nz (247.31.255.123.static.snap.net.nz [123.255.31.247]) by viper.snap.net.nz (Postfix) with ESMTP id AA97D3DA488; Thu, 15 Nov 2007 08:18:08 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 605A08FC6D; Thu, 15 Nov 2007 08:18:01 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18235.18919.959418.360780@kahikatea.snap.net.nz> Date: Wed, 14 Nov 2007 19:18:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [8/9] multiple locations In-Reply-To: <200711141047.03166.ghost@cs.msu.su> References: <18233.20228.172834.464875@kahikatea.snap.net.nz> <18234.40538.721148.831465@kahikatea.snap.net.nz> <200711141047.03166.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 23.0.50.46 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: 2007-11/txt/msg00276.txt.bz2 >... > I think the right approach would be moving the check for loc->shlib_disabled > later, like this: > > if (b->loc == NULL) > ui_out_field_string (uiout, "addr", ""); > else if (header_of_multiple) > ui_out_field_string (uiout, "addr", ""); > else if (loc->shlib_disabled) > ui_out_field_string (uiout, "addr", ""); > else > ui_out_field_core_addr (uiout, "addr", loc->address); > > But there's also testsuite to be updated and getting somebody to > actually approve this patch. OK, but it looks much a smaller/simpler patch than the one you've already committed. > > > But generally, trying to keeping CLI back compatible have to stop > > > at some time -- if we keep this "don't break CLI clients even if > > > CLI clients were deprecated from some time" attitude, it will result > > > in new features being available via MI only. > > > > Focussing on the issue at hand, we're just talking about making a minor > > adjustment to the format of "info breakpoints", for the case of pending > > breakpoints, to avoid breaking existing frontend(s). > > Not quite. We're trying to please frontend(s) using deprecated protocol. > However little time is spent on that, it's time not spent on other, better > things. Is there a reason Emacs website cannot say "Use MI support, > available at http://..."? The short answer is that, although I have a mode that works with MI, it is currently worse than the current one, which uses a mixture of MI and CLI commands. Even if it was as good, there would still be many people already using Emacs 22.1 who wouldn't be aware of the website, or willing/able to update Emacs from it. Also MI is still evolving. It's interesting that you suggest all frontends should use it as the changes you have just made for breakpoints with multiple locations appear in the output of "info breakpoints" but not in that of "-break-list". So I don't see how any front end could handle this information through MI. Unfortunately, the full transition to MI will be a slow one for Emacs. -- Nick http://www.inet.net.nz/~nickrob