From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4624 invoked by alias); 14 Nov 2007 19:38:30 -0000 Received: (qmail 4614 invoked by uid 22791); 14 Nov 2007 19:38:29 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Nov 2007 19:38:25 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1IsO41-0007RS-Ex for gdb-patches@sources.redhat.com; Wed, 14 Nov 2007 22:38:22 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1IsO3r-0007Qz-Um; Wed, 14 Nov 2007 22:38:08 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: [8/9] multiple locations Date: Wed, 14 Nov 2007 19:38:00 -0000 User-Agent: KMail/1.9.6 References: <18233.20228.172834.464875@kahikatea.snap.net.nz> <200711141047.03166.ghost@cs.msu.su> <18235.18919.959418.360780@kahikatea.snap.net.nz> In-Reply-To: <18235.18919.959418.360780@kahikatea.snap.net.nz> Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711142238.06000.ghost@cs.msu.su> 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/msg00279.txt.bz2 On Wednesday 14 November 2007 22:17:59 you wrote: > >... > > 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. Yes, but I have better luck getting huge patches approved, than for obvious patches, for whatever reasons. Basically, it boils down to: 1. Using like above seems a good idea to try. 2. There's a bit of time involved 3. I'm short of time, and probably won't spend it until all the patches I've sent already are reviewed ;-) So, if you have the time now to adjust your current patch per my comments, adjust testsuite and somebody's willing to approve the patch -- go ahead. > > > > 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. Is there a way to package MI support separately, so that every existing Emacs user can try 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. Heh, you probably know what's going on here yourself. Even though MI was advertised as the right interface for frontend for some years, it does not have a maintainer, or a particular development plan, and misses some bits. And probably the only way to change the situation is to decide that MI is the future, and actively discourage use of CLI for anything, to the degree of immediately refusing any request mentioning CLI in relation to any frontend. As for multiple breakpoints -- I would have being happy to provide MI interface, and not provide CLI at all -- but I doubt that would have being acceptable, and MI has fallen out. Again, a policy that new advanced functionality is allowed to be available via MI only might have helped. - Volodya