[Bug breakpoints/14733] GDB/MI output syntax inaccuracy while adding a multiple location breakpoint

[simon.marchi at ericsson dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14733

Simon Marchi <simon.marchi at ericsson dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |simon.marchi at ericsson dot com

--- Comment #1 from Simon Marchi <simon.marchi at ericsson dot com> ---
I just stumbled on this bug, it's still present as of today.

[simon.marchi at ericsson dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14733

Simon Marchi <simon.marchi at ericsson dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |marc.khouzam at ericsson dot com

[marc.khouzam at ericsson dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14733

--- Comment #2 from Marc Khouzam <marc.khouzam at ericsson dot com> ---
Simon pointed out this bug and after looking at how the output is handled in
Eclipse, I wanted to clarify that currently, all the extra tuples specifying
locations are being ignored by Eclipse as it does not follow the expected
format. That was a good think in a way because things probably would have
broke in a worse way had each location been parsed as a separate breakpoint.

I think that when fixing this, we should make sure the locations don't end up
looking like main breakpoints.

[lists.ban at herbesfolles dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14733

lists.ban at herbesfolles dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |lists.ban at herbesfolles dot org

--- Comment #3 from lists.ban at herbesfolles dot org ---
Bit me today, still not fixed in 7.10.

I can understand if the original breakpoint reporting didn't support
multiple-location ones it was useful not to break the result syntax so not
wrapping the breakpoints in a list, but a better solution would have been e.g.
adding a new key to the first one and listing the secondary breakpionts there,
like `bkpt={..., locations=[{...},{...}]}` or something.

Currently a conforming GDB/MI parser will choke on the results here, as it's,
as stated, not conforming to the general documented syntax. Special-casing
this in client apps would be a pain.

[simon.marchi at ericsson dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14733

--- Comment #4 from Simon Marchi <simon.marchi at ericsson dot com> ---

I can understand if the original breakpoint reporting didn't support multiple- location ones it was useful not to break the result syntax so not wrapping the breakpoints in a list, but a better solution would have been e.g. adding a new key to the first one and listing the secondary breakpionts there, like `bkpt={..., locations=[{...},{...}]}` or something.

I don't think the current format (non-conforming MI) was chosen on purpose.
But I agree that the format:

`bkpt={..., locations=[{...},{...}]}`

would make sense. Adding a new key to a MI tuple should not break any
front-end.

[simon.marchi at ericsson dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14733

Simon Marchi <simon.marchi at ericsson dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE

--- Comment #5 from Simon Marchi <simon.marchi at ericsson dot com> ---
Duplicate.

*** This bug has been marked as a duplicate of bug 9659 ***