This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [RFC] Fix the MI result of -break-insert with multiple locations
> -----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.
>
>