From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28091 invoked by alias); 17 Apr 2008 10:17:49 -0000 Received: (qmail 28081 invoked by uid 22791); 17 Apr 2008 10:17:48 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Apr 2008 10:17:21 +0000 Received: from kahikatea.snap.net.nz (162.63.255.123.dynamic.snap.net.nz [123.255.63.162]) by viper.snap.net.nz (Postfix) with ESMTP id 625443DA7D5; Thu, 17 Apr 2008 22:17:18 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 3DFA88FC6D; Thu, 17 Apr 2008 22:17:14 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18439.9128.907701.745181@kahikatea.snap.net.nz> Date: Thu, 17 Apr 2008 12:35:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/RFC] Report the original location specification for a breakpoint. In-Reply-To: <200804171359.09556.vladimir@codesourcery.com> References: <200804151434.57665.vladimir@codesourcery.com> <20080417025749.GA18352@caradoc.them.org> <200804171359.09556.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.2.50.2 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-04/txt/msg00330.txt.bz2 > > Isn't this going to affect more than MI? I thought the text from > > ui_out_field_string was displayed for console too, just without the > > label. > > I don't this so, but I'll check. We can always make this field output > just for MI. It's used by "info breakpoints". > > This definitely needs documentation to go in. I can't say this > > enough. Undocumented fields in the MI output might as well not exist. There are already many other fields that aren't documented, e.g., pending, what, cond, ignore etc. In fact the MI output of -break-insert is very variable. > Yes, of course. > > > Beyond those, I don't see a problem with it. Though wouldn't we like > > to display this in the CLI sometimes too? > > I have no idea. I'd much rather have somebody else decide what CLI should > contain. > > - Volodya > > > -- Nick http://www.inet.net.nz/~nickrob