[Bug mi/9659] -break-list can produce non MI compliant output

[dimitar.zhekov at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9659

Dimitar Zhekov <dimitar.zhekov at gmail dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |dimitar.zhekov at gmail dot
| |com

--- Comment #2 from Dimitar Zhekov <dimitar.zhekov at gmail dot com> 2012-06-09 16:04:18 UTC ---
The bug is still present in 7.4.1. Additionally, multiply-location breakpoints
generate non-compliant output as well:

^done,BreakpointTable={nr_rows="2",nr_cols="6",hdr=[...],body=[bkpt={number="3",...},{number="3.1",...}]}

According to "GDB/MI Output Syntax", a list can (a) be empty, (b) contain
values or (c) contain results. But in the above output, body contains both
result and value.

The async break messages in 7.4+ have the same type of error:

=breakpoint-created,bkpt={number="3",...},{number="3.1",...}

contains both result and value, but async output may include results only.

In general, it's safer to assume that both list and tuple may contain a mix of
results and values. At this point, it may be better to change the
documentation...

[dimitar.zhekov at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9659

--- Comment #3 from Dimitar Zhekov <dimitar.zhekov at gmail dot com> 2012-06-09 16:14:03 UTC ---
Almost forgot: -break-insert for multiply-location breakpoints generates
invalid output too:

^done,bkpt={number="3",...},{number="3.1",...}

same as the async breakpoint messages.

[david.narvaez at computer dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=9659

David E. Narváez <david.narvaez at computer dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |david.narvaez at computer
| |dot org

[david.narvaez at computer dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=9659

--- Comment #4 from David E. Narváez <david.narvaez at computer dot org> 2012-06-19 17:29:41 UTC ---
Created attachment 6458
--> http://sourceware.org/bugzilla/attachment.cgi?id=6458
Display breakpoint commands as a list

I don't think there's any reason to display breakpoint commands as a tuple,
even if there's only one, so this patch simply changes the output from a tuple
to a list.

[david.narvaez at computer dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=9659

--- Comment #5 from David E. Narváez <david.narvaez at computer dot org> 2012-06-19 17:32:10 UTC ---
Created attachment 6459
--> http://sourceware.org/bugzilla/attachment.cgi?id=6459
Display sub-breakpoints in the correct tuple format

Add a variable name to the tuples that are displayed as sub-breakpoints in a
multiple breakpoints scenario.

[david.narvaez at computer dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=9659

--- Comment #6 from David E. Narváez <david.narvaez at computer dot org> 2012-06-19 17:38:59 UTC ---
Is there any developer taking care of these issues? I added a couple of patches
to address some of the issues reported to see if we can get into the technical
and administrative discussions required, but there's not much users can do if
there's no developer to discuss with.

What else do we need to do to have this fixed?

[dimitar.zhekov at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9659

--- Comment #7 from Dimitar Zhekov <dimitar.zhekov at gmail dot com> 2012-06-20 18:21:19 UTC ---
As you can see, it's unassigned since 2008... I don't even think that fixing
the output is a good idea at this point: it may break all the front-ends, and
will force their authors to support both variants for some time, adding
complexity. And it's not like using the right formats will provide any more
functionality/information - that's more a fix for the sake of fixing. Changing
the documentation will "fix" it just as well, without breaking the existing
code.

I respect your effort though, probably took you quite a time...

[david.narvaez at computer dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=9659

--- Comment #8 from David E. Narváez <david.narvaez at computer dot org> 2012-06-20 19:25:08 UTC ---
(In reply to comment #7)

Post by dimitar.zhekov at gmail dot com
As you can see, it's unassigned since 2008... I don't even think that fixing
the output is a good idea at this point: it may break all the front-ends, and
will force their authors to support both variants for some time, adding
complexity. And it's not like using the right formats will provide any more
functionality/information - that's more a fix for the sake of fixing. Changing
the documentation will "fix" it just as well, without breaking the existing
code.

IIUC, that is to say we should ignore this bug because it has been ignored for
quite long. Extending this to every open bug in the bug tracker gives us an
easy way to drop the bug count to zero.

If fixing this will break frontends, well, the bugs themselves broke parsers in
those frontends and it doesn't look like anybody cares, so why would it matter
now? Plus, complex code for supporting two versions is as complex as the code
for supporting special cases of outputs, just that supporting a couple of
versions for some time is temporary.

That being said, I'm not a GDB developer so I can't take those decisions. What
I would like, though, is to see _any_ decision about these as I'm a frontend
developer and I need to know what will the final format of multiple breakpoints
be if there is an open bug about it.

[dimitar.zhekov at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9659

--- Comment #9 from Dimitar Zhekov <dimitar.zhekov at gmail dot com> 2012-06-21 19:06:51 UTC ---
Your point is valid, of course. But once again: the right formats will not
provide any more or better MI functionality.

I am a front-end developer as well. Discarding the difference between list and
tuple, and allowing a mix of named and unnamed arguments, produced a bit
simpler parser for me. But I was only checking the presence or lack of names to
make sure that the output is MI-compliant anyway. Your approach may be
different.

However, "bkpt=" for locations will affect me. :( When a breakpoint lacks
"type=...", my break parsing tries the tuple name next, as in "done,wpt={...}".
So I, too, would like to know what the final MULTIPLE format will be.

[niko.sams at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9659

Niko Sams <niko.sams at gmail dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |niko.sams at gmail dot com

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9659

Tom Tromey <tromey at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at redhat dot com

--- Comment #10 from Tom Tromey <tromey at redhat dot com> 2012-12-19 16:10:47 UTC ---
The best way to send patches is to the list, following
http://sourceware.org/gdb/contribute/

[gobisha6355 at gmail dot com]

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

shanjay <gobisha6355 at gmail dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
Status|ASSIGNED |NEW
Component|mi |core
Version|6.8 |unspecified
Product|gdb |netresolve
Severity|normal |critical

[schwab at sourceware dot org]

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

Andreas Schwab <schwab at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P3
Status|NEW |ASSIGNED
Component|core |mi
Version|unspecified |6.8
Product|netresolve |gdb
Severity|critical |normal

[bugmenot at mailinator dot com]

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

--- Comment #11 from John Doe <bugmenot at mailinator dot com> ---
This is still present in 8.1.1.

Currently, pygdbmi (https://github.com/cs01/pygdbmi) does not support the
broken format (and may cause infinite loop while parsing the output), and it is
linked from GDB Front Ends - GDB Wiki
(https://sourceware.org/gdb/wiki/GDB%20Front%20Ends).

Also, the fix is relatively simple, just change "tuple" to "list".

It should be fixed.

At this version, the code is changed and the patch cannot be directly applied;
but I think the relevant code is at line 6313 of gdb/breakpoint.c
(https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/breakpoint.c;hb=c44deb735ef492f8799cbb35c5f2566fc2dba19d#l6313)
instead.

ui_out_emit_tuple tuple_emitter (uiout, "script");

[[e-mail]]

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

--- Comment #12 from ***@sphinx-net-ru.bounceio.net ---
Your email was bounced...
-------------------------

... because something went wrong between you and your recipient. Oh
no!


What to do next?
----------------

Well, your specific problem was a *5.1.2 * error.

Which means you should: Check the "sphinx.net.ru" part of
"***@sphinx.net.ru" for misspellings or missing letters. If you find
an error, correct it in your contacts list or address book for next
time.

Or further: It is possible that the domain is temporarily inactive. If
the spelling looks correct, contact your mail provider and if
necessary, contact your recipient another way (e.g., phone or text
message).

Get more help on 5.1.2 errors here![1]

Thanks, have a lovely day.

Yours truly, betterbounces.net[2]

Rate this email: Helpful[3] :) or... Not Helpful[4] :(

Advertisement | Prefer no ads?[5]

Learn more about RevenueStripe... [6]

[7]

---------------------------------------------------------------------

© 2017 betterbounces.net, All rights reserved. Privacy[8]

[IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE]

1.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K_2GABZKJKRUCr9eH0qoSHQggFox6HYDpmqyOmHooBm6dXt53X6_meBdlwHdw.NLptk8avIY_bkNtW2pry_fyynXXPma7jEmulvowWSmv9jB00f6LGIlBzu4rqccaQAzhe9QPiJ.NewtZqD2vUAlIMwbcgz_kivUcOhyaVuawoG6Lh0QzX12UhWG48Yu6RrqlPHoyb15B6Hn7NxDC5159hQTocPLOQOJ9OrOblYuJB.1qZI8tAftCBEklmXSdOYJ6rQ9YKdM0QP6.6Zxse1Gw3kzQRfdsDkRWNmnZnxqiPp6ktra8GjGcw8-
2.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K.21it.R1m5hC2I73_QVk2r7gmhEMt..ecGxFyMtSjhv9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxVwOAjjam3qwa1jLaAvk31YHpSg3IEpKHTUY2Bc9vNR1mKhEfLa2b5.66BTX9jN8YOtkkrty7Pipaj6OcOoMywl
3.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K_2GABZKJKRU8qyDV52siqk2XxdSOjm4r0ypfQX7wFOWTRdCQ8V2cSmG233c.jRwmwWu3UhhNGNXfu8SfjeTlH50efaJldzo2sseKGDNy4BK7uWBde7SVWU44CuFfycre.Qr11viOpUaPmbq7b75U2JwXFyG7z.4ax6Ntt5DcBo4rNfPA4fCqhzp4f.Fs_S6kPGl45Swad2yHUmF6hezhcaA6aC5DF1aKL.gbI8DD3jlH5AdvUYmI28ydrwUWMlMHUKaSqAACxurgUF9cZ6E.h4ORje8vKbThJ2pChlk4PmDMyHWSzG_lXRZ8nLhbdxMNYfo8XPiNFng
4.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K_2GABZKJKRU8qyDV52siqk2XxdSOjm4r0ypfQX7wFOWTRdCQ8V2cSmG233c.jRwmwWu3UhhNGNXfu8SfjeTlH50efaJldzo2sseKGDNy4BK7uWBde7SVWU44CuFfycre.Qr11viOpUaPmbq7b75U2K2VoNtaKhIS3HGVDi0bcygCjXMYG6QuPS9HrrRq5iq1bPiOUUtCst5k2CEG_aUoP98JtaSuZfmCMbECjzZ29.96ChhDLeZWMfAYpf6OPi2Kr8Kd94C06XNJJZl0nTmCeq0PWCnTNED_v_mcbHtRsN5M0EX3bA5EVjZp2Z8aoj6epLa2vBoxnMP
5.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K65xQ60lYfy0flGDWEsLbV1IrEnt1r1xObIVZO_G7WWD1M7E7whZuUb6eHJ.II6YeWIxTUh6IPESRj13LY_AdVNmlfpToEFexWWtcakKAdOgWubVaMeR10woGQp.6GXlplzGpKa1Sj_LlpY0u2QsssNw3pe4fnfU7pD8xC5ekq4EbTC5QNhTCg3RpjJqrJ06I89vb9x.zw.ETie7PwK4igpWyBd_6v5bmJtJ3AbIJl.tzMn9oVpQ3Eom3g5_7fl73qxD58z5JmdG5uCGc1BZzgveYjpI8C8PhjWc1wzm6W5jrrweds0uOCUoaQ3UPvIYSg3SqCUudGEbVfbjWktIwy2wAGb2pBpCkqzuDLgIi4E5_joSbScs0fPAlz5kZcxNcMJYmOnCceS4LB1TH3QUAp39NPpQGXeVJXo.iyx4WT2099gh7F.iFWPfv4skDAs4FyPZKzdD.21cNexd_VRCfj0ZKeVZpVf6mYP180S6LXIvh7KGScCVrc_LA4AWd6nqMBoGeMzEntu5r4bIDp4Ee1DGPOdSRj1EW70eutGrmKrVp3nwg6JfWjvstRAboUmTZYMVtiJgtncOgrI9g610pCZ5k10HltuL9r0qNGUZ37yq1JqAZNuwM2OzEtKEB3G58dZiqFi2CwrA
6.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K.50VzfMb4zIZvoeThG7cD_Hq5OYMcpU2Gh2MYgq2PxGYEj6a3kxnWJ.M8ljiVXC0iqkTTlchP2EO0_uWEiuOSsUNFKEBtdnltNH_ixiJQc7B1D4tnSPG6dv0n7Hni9K8mo0seCMg7k8tWzeGGmB.32hF9B32Ro9_LYrU.dViNedO05SOro6Kjw0e58bul8AzwhLM6e8f3lepL3igdncrp1CAuvLcI3WN3Ca.zo1NwqjQppKoAALG6uBQX1xnoT_Hg5GN7y8ptOEnakKGWTg_YMzIdZLMb6VdFnycuFt3Ew1h_jxc_I0WeA-
7.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K3GyZ1ErduqIsj4NgKtCp5iXhfljAGUSXkoKMyoK1mu_GhPanZmrwhIZ4Ebx2E0KCCu_nVPqmlBy63gtqB94Jthu6FbUC88xL50h3GVgWD5KoTzKalb6rUqnoSgYeP6O46qBEgyjtu0GmFEoGmaqciE7ylQkbJKgf_Ax1EZwN1HlNyyRvWjmMFtodRLaFvGukNiWr2j6MlrcIp9L_GrgwGYaBnjMxJ7bua_GyA6eBHtQxjznUkY9RFu9HrrRq5iq1ad58IOiX1o77LUQG6FJk2WDFbYiYLZ3DoKyPYOtdKQmeZNdB5bbi.a9KjRlGd_8qtSagGTbsDNjsxLShAdxufHWYqhYtgsKwA--
8.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K_2GABZKJKRUCr9eH0qoSHQggFox6HYDpi9V2pT3EOyXHac8Tbord_6y3CM5bROCAxoGeMzEntu5r4bIDp4Ee1DGPOdSRj1EW70eutGrmKrVp3nwg6JfWjvstRAboUmTZYMVtiJgtncOgrI9g610pCZ5k10HltuL9r0qNGUZ37yq1JqAZNuwM2OzEtKEB3G58dZiqFi2CwrA

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC|dima at sphinx dot net.ru |tromey at sourceware dot org

--- Comment #13 from Tom Tromey <tromey at sourceware dot org> ---
Removing the spam address.

Historically this bug has never been fixed because all existing
MI consumers have discovered this bug and worked around it,
and so now gdb has been afraid to correct this for fear of
breaking said consumers.

This is not ideal of course. I've always seen it as a consequence
of the lack of a communication channel between gdb developers
and MI consumer developers; like maybe some sort of low traffic
gdb-mi list would have helped break the logjam.

Maybe another way out would be to start work on a new version of MI
and let consumers opt in.

Or maybe, just land the patch and try to warn the consumer developers.

[[e-mail]]

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

--- Comment #14 from ***@sphinx-net-ru.bounceio.net ---
Your email was bounced...
-------------------------

... because something went wrong between you and your recipient. Oh
no!


What to do next?
----------------

Well, your specific problem was a *5.1.2 * error.

Which means you should: Check the "sphinx.net.ru" part of
"***@sphinx.net.ru" for misspellings or missing letters. If you find
an error, correct it in your contacts list or address book for next
time.

Or further: It is possible that the domain is temporarily inactive. If
the spelling looks correct, contact your mail provider and if
necessary, contact your recipient another way (e.g., phone or text
message).

Get more help on 5.1.2 errors here![1]

Thanks, have a lovely day.

Yours truly, betterbounces.net[2]

Rate this email: Helpful[3] :) or... Not Helpful[4] :(

Advertisement | Prefer no ads?[5]

Learn more about RevenueStripe... [6]

[7]

---------------------------------------------------------------------

© 2017 betterbounces.net, All rights reserved. Privacy[8]

[IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE]

1.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K_2GABZKJKRUCr9eH0qoSHQggFox6HYDpmqyOmHooBm6dXt53X6_meBdlwHdw.NLptk8avIY_bkNtW2pry_fyynXXPma7jEmulvowWSmv9jB00f6LGIlBzu4rqccaQAzhe9QPiJ.NewtZqD2vUAlIMwbcgz_kivUcOhyaVuawoG6Lh0QzX12UhWG48Yu6RrqlPHoyb15B6Hn7NxDC5159hQTocPLOQOJ9OrOblYuJB.1qZI8tAftCBEBSnwvrX40kjxKuCm.4Kn3B7J3tEs2dnzwQhvvxuLB4Zn30ANbge6Ncy9P.hzZi7Y-
2.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K.21it.R1m5hC2I73_QVk2r7gmhEMt..ecGxFyMtSjhv9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxVwOAjjam3qwa1jLaAvk31YMyK1DZfz19E79Q3a9g_FEr0Uw_G4Vmt0_vaSj_CDAHo428HgkJS4XpHCG0YWzj2Q
3.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K_2GABZKJKRU8qyDV52siqk2XxdSOjm4r0ypfQX7wFOWTRdCQ8V2cSmG233c.jRwmwWu3UhhNGNXfu8SfjeTlH5Z7h1uzijqEjAQ2rlTuL5R0nklehvG.pwRiIsRPwe9YNToiM5sP7hlPmbq7b75U2JwXFyG7z.4ax6Ntt5DcBo4rNfPA4fCqhzp4f.Fs_S6kPGl45Swad2yHUmF6hezhcaA6aC5DF1aKL.gbI8DD3jlH5AdvUYmI28ydrwUWMlMHUKaSqAACxur99Unet8LS6HqemWWSeCPAw6_C2Yu1VlVyf_4OTcfQwVGWNrqDNwqYofo8XPiNFng
4.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K_2GABZKJKRU8qyDV52siqk2XxdSOjm4r0ypfQX7wFOWTRdCQ8V2cSmG233c.jRwmwWu3UhhNGNXfu8SfjeTlH5Z7h1uzijqEjAQ2rlTuL5R0nklehvG.pwRiIsRPwe9YNToiM5sP7hlPmbq7b75U2K2VoNtaKhIS3HGVDi0bcygCjXMYG6QuPS9HrrRq5iq1bPiOUUtCst5k2CEG_aUoP98JtaSuZfmCMbECjzZ29.96ChhDLeZWMfAYpf6OPi2Kr8Kd94C06XNAUp8L61_NJI8Srgpv_Cp9weyd7RLNnZ88EIb78biweGZ99ADW4HujXMvT.4c2Yu2
5.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K65xQ60lYfy0flGDWEsLbV1IrEnt1r1xObIVZO_G7WWD1M7E7whZuUb6eHJ.II6YeWIxTUh6IPESRj13LY_AdVNmlfpToEFexWWtcakKAdOgWubVaMeR10woGQp.6GXlplzGpKa1Sj_LlpY0u2QsssNw3pe4fnfU7pD8xC5ekq4EbTC5QNhTCg3RpjJqrJ06I89vb9x.zw.ETie7PwK4igpWyBd_6v5bmJtJ3AbIJl.tzMn9oVpQ3Eom3g5_7fl73qxD58z5JmdG5uCGc1BZzgveYjpI8C8PhjWc1wzm6W5jrrweds0uOCUoaQ3UPvIYSg3SqCUudGEbVfbjWktIwy2wAGb2pBpCkqzuDLgIi4E5_joSbScs0fPAlz5kZcxNcMJYmOnCceS4LB1TH3QUAp39NPpQGXeVJaWCuIkBLkH3KQjCbaKf9kNBZeYbmEszpV6ge1bnl_Oh4RRAGgTiaLM2BS93B6dK2tMDvvAnHvWmh7KGScCVrc_LA4AWd6nqMBoGeMzEntu5r4bIDp4Ee1DGPOdSRj1EW70eutGrmKrVp3nwg6JfWjvstRAboUmTZYMVtiJgtncOOYzJs9N6cM9OWJ9MO290IX9Gqapy49nPVud3BKvSRgZ0Iugtruoz4NZiqFi2CwrA
6.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K.50VzfMb4zIZvoeThG7cD_Hq5OYMcpU2Gh2MYgq2PxGYEj6a3kxnWJ.M8ljiVXC0iqkTTlchP2EO0_uWEiuOSsUNFKEBtdnltNH_ixiJQc7B1D4tnSPG6dv0n7Hni9K8mo0seCMg7k8tWzeGGmB.32hF9B32Ro9_LYrU.dViNedO05SOro6Kjw0e58bul8AzwhLM6e8f3lepL3igdncrp1CAuvLcI3WN3Ca.zo1NwqjQppKoAALG6v31Sd63wtLoep6ZZZJ4I8DDr4LZi7VWVXJ.7g5Nx9DBUZY2uoM3Cpih_jxc_I0WeA-
7.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K3GyZ1ErduqIsj4NgKtCp5iXhfljAGUSXkoKMyoK1mu_GhPanZmrwhIZ4Ebx2E0KCCu_nVPqmlBy63gtqB94Jthu6FbUC88xL50h3GVgWD5KoTzKalb6rUqnoSgYeP6O4_QCTDwcj7Tf2pBoKia9KkM7ylQkbJKgf_Ax1EZwN1HlNyyRvWjmMFtodRLaFvGukNiWr2j6MlrcIp9L_GrgwGYaBnjMxJ7bua_GyA6eBHtQxjznUkY9RFu9HrrRq5iq1ad58IOiX1o77LUQG6FJk2WDFbYiYLZ3DjmMybPTenDPTlifTDtvdCF.RqmqcuPZz1bndwSr0kYGdCLoLa7qM_DWYqhYtgsKwA--
8.
https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbcR7tgLvKz0cwndbny0WbpfpbeeM_N_xg8Hh1mgQFaUDbwmnFI4wq2HWTN_jaXUWK5aYgcgEa4o3pks8Vx9jMP9ucACXr9YIjPSIa1p5uj07hNB88h9Th9.bW.u2j4gxUicnCj.1X4K_2GABZKJKRUCr9eH0qoSHQggFox6HYDpi9V2pT3EOyXHac8Tbord_6y3CM5bROCAxoGeMzEntu5r4bIDp4Ee1DGPOdSRj1EW70eutGrmKrVp3nwg6JfWjvstRAboUmTZYMVtiJgtncOOYzJs9N6cM9OWJ9MO290IX9Gqapy49nPVud3BKvSRgZ0Iugtruoz4NZiqFi2CwrA

[[e-mail]]

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

--- Comment #15 from ***@sphinx-net-ru.bounceio.net ---
Created attachment 11202
--> https://sourceware.org/bugzilla/attachment.cgi?id=11202&action=edit
attachment-46996-1.eml

[simon.marchi at ericsson dot com]

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

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

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

[simon.marchi at ericsson dot com]

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

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

What |Removed |Added
----------------------------------------------------------------------------
CC| |nikolay.koldunov at oracle dot com

--- Comment #16 from Simon Marchi <simon.marchi at ericsson dot com> ---
*** Bug 14733 has been marked as a duplicate of this bug. ***

[tromey at sourceware dot org]

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

--- Comment #17 from Tom Tromey <tromey at sourceware dot org> ---
We discussed some options on irc today.

One is a new command, like -break-list-2.
Another is to roll out an experimental MI version 4 that fixes
bugs and then, eventually, bless it.
Another is the same, but let the front end pick the MI version
per-command, maybe via an option or maybe via a prefix command.
Another is to have an enabling command like -enable-pretty-printing,
but to fix specific compatibility bugs, like -fix-break-list-bug
or some such.

[lists.ban at herbesfolles dot org]

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

Colomban Wendling <lists.ban at herbesfolles dot org> changed:

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

[palves at redhat dot com]

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

Pedro Alves <palves at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at redhat dot com

--- Comment #18 from Pedro Alves <palves at redhat dot com> ---
I wasn't involved in the irc discussion, but I've discussed this with Simon
before. Adding my 2c.

IMO, we should go the -break-list-2 route.

Tying command fixes to MI versions (like the v4 idea) is an inferior solution
IMO, because then you can't e.g., backport individual command fixes. It's an
either all-or-nothing solution. To get a fix present in v6, you need all of
v3, v4, v5.

I'd think a jump of MI version would only be justified when we want to change
something fundamental that would break compatibility across manhy commands and
events, like switching to json, or changing how lists/tuples/etc. are
represented, or something like that.

[perret at mailbox dot org]

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

perret at mailbox dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |perret at mailbox dot org

--- Comment #19 from perret at mailbox dot org ---
As a frontend implementor I'm in favor of a new mi version. The frontend I'm
working on (https://github.com/occivink/kakoune-gdb) uses new-ui such that the
user can control gdb from either the IDE or the gdb cli. Introducing a new
-break-insert-2 wouldn't work in my case because I receive both synchronous and
asynchronous outputs, and this mechanism does not control the async format.

My preferred solution would be an mi4-experimental with no stability guarantee
where breaking changes are progressively accumulated, to be renamed to mi4
after some time. I also think this should be used to make all possible outputs
compliant with the grammar. The format should be simple to parse, but instead
each frontend implementor has to waste time discovering this bug and
introducing hacks to work around it.

[palves at redhat dot com]

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

--- Comment #20 from Pedro Alves <palves at redhat dot com> ---
Thanks for the input. That's a good point on the async format, I did not know
that was broken as well. In that case, the "-fix-break-list-bug" solution
would also work for you too, right? We could later on say that MI3 is like MI2
with "-fix-break-list-bug" + "-whatever-else", etc. on by default, and so
forth. Kind of like each OpenGL revision incorporates features that were
previously extensions.

The format should be simple to parse, but instead each frontend implementor has
to waste time discovering this bug and introducing hacks to work around it.

I think the main problem with discovery is that we don't warn clearly about the
bad format in the manual.

[perret at mailbox dot org]

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

--- Comment #21 from perret at mailbox dot org ---

In that case, the "-fix-break-list-bug" solution would
also work for you too, right?

Right, I didn't realize that this proposed solution would be a global switch,
that would work as well.