Bug 9659 - -break-list can produce non MI compliant output
Summary: -break-list can produce non MI compliant output
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: mi (show other bugs)
Version: 6.8
: P3 normal
Target Milestone: 9.1
Assignee: Not yet assigned to anyone
URL:
Keywords: mi3
: 10389 14733 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-11-13 12:48 UTC by Dodji Seketeli
Modified: 2019-03-16 19:44 UTC (History)
10 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Display breakpoint commands as a list (248 bytes, patch)
2012-06-19 17:29 UTC, David E. Narváez
Details | Diff
Display sub-breakpoints in the correct tuple format (357 bytes, patch)
2012-06-19 17:32 UTC, David E. Narváez
Details | Diff
attachment-46996-0.dat (139 bytes, message/delivery-status)
2018-08-21 14:42 UTC, postmaster
Details
attachment-46996-1.eml (1.21 KB, message/rfc822)
2018-08-21 14:42 UTC, postmaster
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dodji Seketeli 2008-11-13 12:48:02 UTC
[Converted from Gnats 2554]

Suppose I am using gdb --interpreter=mi2 to debug a program with a .gdbinit that contains:
b info_command
commands
 silent
 return
end

Then I set a breakpoint in main, doing "-break-insert main".

When I do "-break-list", I get an MI output record that I believe is not MI compliant:

~=~
^done,BreakpointTable={nr_rows="3",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="18",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000044f7d0",func="internal_error",file="utils.c",fullname="/home/dodji/devel/git/archer.git/gdb/utils.c",line="964",times="0"},bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x000000000048ec10",func="info_command",file=".././gdb/cli/cli-cmds.c",fullname="/home/dodji/devel/git/archer.git/gdb/cli/cli-cmds.c",line="198",times="0",script={"silent","return"}},bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000446ec0",func="main",file="gdb.c",fullname="/home/dodji/devel/git/archer.git/gdb/gdb.c",line="26",times="1"}]}
(gdb)
~=~

The part that is not MI compliant here is the result:
script={"silent", "return"}

I believe that is not a valid MI RESULT production, as defined by the grammar at http://sourceware.org/gdb/current/onlinedocs/gdb_26.html#SEC264.

A RESULT has the form:
 VARIABLE "=" VALUE

where VALUE is either a CONST, a LIST, or a TUPLE.

In our case, the VALUE is {"silent", "return"}. This looks like a TUPLE because it starts with a '{', but alas it's not a TUPLE because a TUPLE should have the form:
"{}" | "{" RESULT ( "," RESULT )* "}"

where, again, RESULT has the form: VARIABLE "=" VALUE.

So, I think we should have script = ["silent", "return"] instead, where ["silent", "return"] is a LIST, not a TUPLE.
That would be at least compliant with the MI grammar, and save clients from twistint their MI parsers to make those understand non MI compliant constructs.

From a quick first glance, it seems to appear that the function print_one_breakpoint_location() reads at some point:
script_chain = make_cleanup_ui_out_tuple_begin_end (uiout, "script");

That could suggests the deliberate generation of a tuple here, where I believe it should be a LIST generation instead. Maybe that could be a starting point of investigation.

Release:
6.8

Environment:
GNU/Linux
Comment 1 Dmitry Dzhus 2009-07-14 12:48:49 UTC
*** Bug 10389 has been marked as a duplicate of this bug. ***
Comment 2 Dimitar Zhekov 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...
Comment 3 Dimitar Zhekov 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.
Comment 4 David E. Narváez 2012-06-19 17:29:41 UTC
Created attachment 6458 [details]
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.
Comment 5 David E. Narváez 2012-06-19 17:32:10 UTC
Created attachment 6459 [details]
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.
Comment 6 David E. Narváez 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?
Comment 7 Dimitar Zhekov 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...
Comment 8 David E. Narváez 2012-06-20 19:25:08 UTC
(In reply to comment #7)
> 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.
Comment 9 Dimitar Zhekov 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.
Comment 10 Tom Tromey 2012-12-19 16:10:47 UTC
The best way to send patches is to the list, following
http://sourceware.org/gdb/contribute/
Comment 11 John Doe 2018-08-20 13:39:33 UTC
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");
Comment 12 postmaster 2018-08-20 13:40:16 UTC
   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
   "dima@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
Comment 13 Tom Tromey 2018-08-21 14:39:51 UTC
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.
Comment 14 postmaster 2018-08-21 14:42:22 UTC
Created attachment 11201 [details]
attachment-46996-0.dat

   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
   "dima@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
Comment 15 postmaster 2018-08-21 14:42:27 UTC
Created attachment 11202 [details]
attachment-46996-1.eml
Comment 16 Simon Marchi 2018-09-26 16:51:53 UTC
*** Bug 14733 has been marked as a duplicate of this bug. ***
Comment 17 Tom Tromey 2018-09-26 20:24:26 UTC
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.
Comment 18 Pedro Alves 2018-09-29 18:57:30 UTC
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.
Comment 19 perret 2018-10-01 15:32:23 UTC
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.
Comment 20 Pedro Alves 2018-10-01 16:32:02 UTC
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.
Comment 21 perret 2018-10-02 07:28:57 UTC
> 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.
Comment 22 Simon Marchi 2019-03-15 01:17:36 UTC
A fix for this has been pushed in the master branch:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=b4be1b064860

It would be appreciated if someone else than me could try it and see if the output is satisfactory, hopefully before the next GDB release (not 8.3, the one after that).

Thank you!