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 5:14 PM
> 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
> 
> 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.

I don't believe eclipse can handle the current output as it stands,
not in the reply to -break-insert at least.  The code expects
a single breakpoint tuple, so we'll need to change things either way.

I'm not saying that is a good enough reason to change the output :)
I'm just mentioning that some frontends can't handle this already.


> 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.
> 
>