From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13799 invoked by alias); 13 Nov 2007 08:31:56 -0000 Received: (qmail 13790 invoked by uid 22791); 13 Nov 2007 08:31:55 -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; Tue, 13 Nov 2007 08:31:53 +0000 Received: from kahikatea.snap.net.nz (107.31.255.123.static.snap.net.nz [123.255.31.107]) by viper.snap.net.nz (Postfix) with ESMTP id 987B53D9F5E; Tue, 13 Nov 2007 21:31:45 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 655AF8FC6D; Tue, 13 Nov 2007 21:31:37 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18233.24808.118388.797786@kahikatea.snap.net.nz> Date: Tue, 13 Nov 2007 08:31:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [8/9] multiple locations In-Reply-To: <200711131105.10906.vladimir@codesourcery.com> References: <18233.20228.172834.464875@kahikatea.snap.net.nz> <200711131105.10906.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 23.0.50.45 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/msg00237.txt.bz2 > > This can break a front end which parses the old output, and this is indeed > > the case for Emacs 22.1, which has already been released. > > The CLI output was never documented as stable, and using it in frontend > is prone to such breakage. It still presumably makes sense to avoid such breakage where possible. > > Does the (p) add anything useful to the user? The manual says: > > > > An optional `(p)' suffix marks pending breakpoints > > > > Is that not clear from the word PENDING? > > No, because if you set breakpoint in a shared library, and that library is > unloaded, you have some number in 'address' field, but the breakpoint won't > actually fire, and the "(p)" indicates that fact. OK, but the column you've added this to is "Enb" which refers to whether the breakpoint is enabled or not. That is really a yes/no question and not related to whether the breakpoint is pending. > > If it's not needed can we please revert it to the old format? If it is > > needed can we find a format that doesn't break existing parsing? > > I personally don't think we should cater for clients that try to use CLI > despite that being known as bad idea. I think we should generally try to cater for _all_ users of GDB and not impose requirements on their use of GDB. > That said -- do you have any > suggestions for an alternative format? Yes I do. Instead of: (gdb) inf bre Num Type Disp Enb Address What 1 breakpoint keep y(p) 0xb7f4ce40 for an unloaded breakpoint, how about: (gdb) inf bre Num Type Disp Enb Address What 1 pending breakpoint keep y 0xb7f4ce40 which seems the right place to put it, and Emacs will parse this properly because that's where other breakpoint variants are described, e.g., 3 hw breakpoint keep y 0x080485bc in main at myprog.c:75 -- Nick http://www.inet.net.nz/~nickrob