RE: [RFC] Fix the MI result of -break-insert with multiple locations

[Marc Khouzam <marc dot khouzam at ericsson dot com>]

> -----Original Message-----
> From: apoe@hrz.tu-chemnitz.de 
> [mailto:apoe@hrz.tu-chemnitz.de] On Behalf Of André Pönitz
> Sent: Tuesday, January 29, 2013 2:45 PM
> To: Mircea Gherzan
> Cc: tromey@redhat.com; vladimir@codesourcery.com; Marc 
> Khouzam; gdb-patches@sourceware.org
> Subject: Re: [RFC] Fix the MI result of -break-insert with 
> multiple locations
> 
> On Tue, Jan 29, 2013 at 03:36:04PM +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 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 believe this invalid output was introduced with 
GDB 7.5.  If it was fixed, an existing or future frontend may choose 
not to support the invalid output and rely on GDB 7.6.  I don't know
yet what we will do in Eclipse but I know that we use GDB 7.5 now
even though we don't parse the special broken output for breakpoints.
So things are not broken enough to force us to support the invalid
output (or at least I haven't realized that they are broken :)).


> The fact that the current output might not conform to the documented
> grammar has no impact to existing frontends as they have/had to cope
> with this kind of slight deviations anyway.
> 
> An alternative approach would be to just make the documentation match
> the actual output. This is not unprecedented.
> 
> Andre'