Steps to reproduce: - create and compile a C++ sample which contains a declaration (in .h file) and a definition (in .cpp file) of a class - execute GDB with "--interpreter mi" parameter - start debugging session - set a function breakpoint for the constructor Actual result: GDB output looks like this: result: variable = value value: tuple (, tuple)* (for example, '15^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",times="0",original-location="Customer::Customer"},{number="2.1",enabled="y",addr="0x0000000000403efe",func="Customer::Customer(Customer const&)",file="customer.h",fullname="/home/henk/tmp/Quote_2/customer.h",line="38"},{number="2.2",enabled="y",addr="0x0000000000404707",func="Customer::Customer(std::string, int)",file="customer.cc",fullname="/home/henk/tmp/Quote_2/customer.cc",line="35"}') Expected result: As you can see in GDB documentation, GDB output should look like this: result: variable = value value: const | tuple | list
I just stumbled on this bug, it's still present as of today.
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.
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.
> 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.
Duplicate. *** This bug has been marked as a duplicate of bug 9659 ***