[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
*** Bug 10389 has been marked as a duplicate of this bug. ***
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...
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.
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.
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.
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?
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...
(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.
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.
The best way to send patches is to the list, following http://sourceware.org/gdb/contribute/
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");
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
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.
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
Created attachment 11202 [details] attachment-46996-1.eml
*** Bug 14733 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
> 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.
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!