From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32200 invoked by alias); 7 Mar 2013 21:44:11 -0000 Received: (qmail 32190 invoked by uid 22791); 7 Mar 2013 21:44:09 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from usevmg21.ericsson.net (HELO usevmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Mar 2013 21:44:01 +0000 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D3.F3.02411.02A09315; Thu, 7 Mar 2013 22:44:01 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 16:43:42 -0500 From: Marc Khouzam To: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= , Mircea Gherzan CC: "tromey@redhat.com" , "vladimir@codesourcery.com" , "gdb-patches@sourceware.org" , "mgherzan@gmail.com" Subject: RE: [PATCH 1/3] MI: fix the result of -break-insert with multiple locations Date: Thu, 07 Mar 2013 21:44:00 -0000 Message-ID: References: <1362076197-15363-1-git-send-email-mircea.gherzan@intel.com> <20130302165337.GA8432@klara.mpi.htwm.de> <5138C0F7.6060703@intel.com>,<20130307205351.GA4065@klara.mpi.htwm.de> In-Reply-To: <20130307205351.GA4065@klara.mpi.htwm.de> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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-03/txt/msg00316.txt.bz2 > On Thu, Mar 07, 2013 at 05:31:51PM +0100, Mircea Gherzan wrote: > > On 02.03.2013 17:53, Andr=E9 P=F6nitz wrote: > > >On Thu, Feb 28, 2013 at 07:29:55PM +0100, Mircea Gherzan wrote: > > >>The current MI output when printing a breakpoint with multiple locati= ons > > >>is not conformant to the MI specification: > > >> > > >> bkpt=3D{number=3D"1", ...},{number=3D"1.1", ...},{number=3D"1.2", = ...} > > >> > > >>This patch fixes this issue by moving the locations to a list inside = the > > >>first tuple: > > >> > > >> bkpt=3D{number=3D"1", ... , locations=3D[{number=3D"1.1", ...}, ..= .]} > > > > > >This breaks GDB frontends that parse the original output. > > > > This has been discussed before. >=20 > As in "we ignored your input". >=20 > > Marc has confirmed that Eclipse does not parse the original output eith= er. >=20 > How does the non-affectedness of a specific frontend matter > in that context? Are there first and second class citizens > when it comes to gdb frontends? I think it may simply be that Mircea is not familiar with the frontend landscape. Eclipse is not the only frontend that uses MI to control GDB. Andre takes care of another such frontend (I apologize but its names escapes me right at this moment). Normally, MI changes should be backwards compatible (even if they are fixing something broken). I have seen that for difficult changes, exceptions were made as long as no one mentioned=20 the change broke a frontend. This is not the case here. > This breaks frontends that parses the original output and do > (obviously...) not understand your changed version.