RE: [PATCH 1/3] MI: fix the result of -break-insert with multiple locations

[Marc Khouzam <marc.khouzam@ericsson.com>]

> On Thu, Mar 07, 2013 at 05:31:51PM +0100, Mircea Gherzan wrote:
> > On 02.03.2013 17:53, André Pönitz wrote:
> > >On Thu, Feb 28, 2013 at 07:29:55PM +0100, Mircea Gherzan wrote:
> > >>The current MI output when printing a breakpoint with multiple locations
> > >>is not conformant to the MI specification:
> > >>
> > >>   bkpt={number="1", ...},{number="1.1", ...},{number="1.2", ...}
> > >>
> > >>This patch fixes this issue by moving the locations to a list inside the
> > >>first tuple:
> > >>
> > >>   bkpt={number="1", ... , locations=[{number="1.1", ...}, ...]}
> > >
> > >This breaks GDB frontends that parse the original output.
> >
> > This has been discussed before.
> 
> As in "we ignored your input".
> 
> > Marc has confirmed that Eclipse does not parse the original output either.
> 
> 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 
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.