From: Vladimir Prus <vladimir@codesourcery.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sources.redhat.com, Dodji Seketeli <dseketel@redhat.com>
Subject: Re: [patch] MI: breakpoint "script" is a LIST
Date: Thu, 13 Nov 2008 20:21:00 -0000 [thread overview]
Message-ID: <200811131834.26373.vladimir@codesourcery.com> (raw)
In-Reply-To: <20081113134113.GA15321@host0.dyn.jankratochvil.net>
[Adding list to CC]
On Thursday 13 November 2008 16:41:13 you wrote:
> On Thu, 13 Nov 2008 14:12:54 +0100, Vladimir Prus wrote:
> > Jan Kratochvil wrote:
> > > Nemiver could not parse the MI2 output. The list of commands is a `list', not
> > > a `tuple'.
> >
> > For how long this bug is here? Is the risk that existing frontend break higher than
> > inconvenience to keep the code as is?
>
> The current code does not comply to any generic MI parser as it violates the
> MI grammar http://sourceware.org/gdb/current/onlinedocs/gdb_26.html#SEC264 ,
> as pointed out by Dodji.
>
> It may be compliant only to some hacky buggy parsers written specifically for
> each MI command.
That's interesting statement -- are you saying all MI frontends out there have
"hacky buggy parsers"?
> If we want to keep -break-list "script" to produce tuples we have to change it
> from current
> script={"silent","return"}
> to some
> script={line0="silent",line1="return"}
> which will IMO also break any existing buggy parsers.
>
> And GDB is now between major releases 6.8->6.9 which IMO means it does not
> have to keep bug-to-bug compatibility.
This breakage is relatively new ;-)
commit b6953506f4d41d46e87650188520283158c37a51
Author: Andrew Cagney <cagney@redhat.com>
Date: Sat May 12 04:08:24 2001 +0000
s/ui_out_list/ui_out_tupple/
@@ -3490,9 +3490,9 @@ print_one_breakpoint (struct breakpoint *b,
{
annotate_field (9);
#ifdef UI_OUT
- ui_out_list_begin (uiout, "script");
+ ui_out_tuple_begin (uiout, "script");
print_command_lines (uiout, l, 4);
- ui_out_list_end (uiout);
+ ui_out_tuple_end (uiout);
But I'm sure all existing frontends handle this. I don't think I'm gonna test
Eclipse (both CDI and DSF), and KDevelop (3.3 and 4), to make sure the proposed
change does not break them. So, we probably get to wait till MI3.
- Volodya
next prev parent reply other threads:[~2008-11-13 15:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-13 15:11 Jan Kratochvil
2008-11-13 15:35 ` Vladimir Prus
2008-11-13 15:39 ` Jan Kratochvil
2008-11-13 20:21 ` Vladimir Prus [this message]
2008-11-13 21:35 ` Tom Tromey
2008-11-13 21:55 ` Marc Khouzam
2008-11-13 21:59 ` Jan Kratochvil
2008-11-16 8:23 ` André Pönitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200811131834.26373.vladimir@codesourcery.com \
--to=vladimir@codesourcery.com \
--cc=dseketel@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox