From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14553 invoked by alias); 29 Jan 2013 22:14:11 -0000 Received: (qmail 14545 invoked by uid 22791); 29 Jan 2013 22:14:10 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nick.hrz.tu-chemnitz.de (HELO nick.hrz.tu-chemnitz.de) (134.109.228.11) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Jan 2013 22:13:38 +0000 Received: from 91-66-49-158-dynip.superkabel.de ([91.66.49.158] helo=localhost) by nick.hrz.tu-chemnitz.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1U0JQs-0007Cw-BL; Tue, 29 Jan 2013 23:13:34 +0100 Date: Tue, 29 Jan 2013 22:14:00 -0000 From: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= To: Marc Khouzam Cc: 'Mircea Gherzan' , "'tromey@redhat.com'" , "'vladimir@codesourcery.com'" , "'gdb-patches@sourceware.org'" Subject: Re: [RFC] Fix the MI result of -break-insert with multiple locations Message-ID: <20130129221333.GA5941@klara.mpi.htwm.de> References: <1359470164-32004-1-git-send-email-mircea.gherzan@intel.com> <20130129194520.GA3727@klara.mpi.htwm.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-purgate: clean X-purgate-type: clean X-purgate-ID: 154106::1359497614-000004D6-7028D006/0-0/0-0 X-Scan-AV: nick.hrz.tu-chemnitz.de;2013-01-29 23:13:34;003b1ecc234ef872f80093613d831149 X-Scan-SA: nick.hrz.tu-chemnitz.de;2013-01-29 23:13:34;ef0e41089ba2a5a8ea0f3b3b7a1fa931 X-Spam-Score: -1.0 (-) X-Spam-Report: --- Textanalyse SpamAssassin 3.3.1 (-1.0 Punkte) Fragen an/questions to: Postmaster TU Chemnitz * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP --- Ende Textanalyse 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: 2013-01/txt/msg00702.txt.bz2 On Tue, Jan 29, 2013 at 08:42:39PM +0000, Marc Khouzam wrote: > > This seems more like an additional burden for frontends which cannot > > rely on a specific gdb version being installed as they have to keep > > code to parse both results, for years. > > Although that is a good point, keeping it forces frontends to deal > with that case. I don't think it needs special "dealing" as I assume that existing frontend parsers are just robust enough to accept such cases. Changing the nesting of structures on the other hand usually needs adjustment to the interpretation of the parsed structure. I am not scared of adding yet another ten lines to find out which kind of output the user's choice of GDB produces and to handle both versions, I just find it not particular convenient. Andre' PS: This point remains: > > An alternative approach would be to just make the > > documentation match the actual output. This is not > > unprecedented. PPS: In theory "-list-features" could be used to announce output changes to avoid the "guessing" phase.