From: Tom Tromey <tom@tromey.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Simon Marchi <simon.marchi@ericsson.com>,
gdb-patches@sourceware.org, palves@redhat.com
Subject: Re: [PATCH] Fix MI output for multi-location breakpoints
Date: Sat, 12 Jan 2019 17:01:00 -0000 [thread overview]
Message-ID: <87pnt1vmhr.fsf@tromey.com> (raw)
In-Reply-To: <83y37qgail.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 11 Jan 2019 23:16:50 +0200")
>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
>> In reality, it's included in all versions from 5.1 and up. So it
>> seems odd to list 5.2 and 5.3 specifically. Do you have a
>> suggestion to address this?
Eli> Say "used by" instead of "included in"?
Yeah, I think that would be clearer. The current text makes it sounds
as though MI1 were limited to just these releases, whereas it's actually
the case that these releases included MI1 but not anything later.
Speaking of, it seems like we could remove MI1.
Eli> That's not what bothered me. What bothered me was that we released a
Eli> GDB with this MI syntax without fixing it first. I'm wondering how to
Eli> prevent such mistakes in the future.
Yeah, this is unfortunate.
Also, I think it is hard to see a programmatic way around this, at least
given gdb's current ui-out approach. As I see it, the problem is that
at a given point, one can make either a tuple emitter or a list emitter,
but otherwise there's no distinction in the source. If you choose the
wrong one this is hard to see in review, and there's really nothing else
checking the grammar.
Maybe the MI ui-out object could somehow enforce the constraint, by
asserting if the wrong thing is done. Though it would need a bypass
anyhow because there are already bugs.
Tom
next prev parent reply other threads:[~2019-01-12 17:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 0:15 Simon Marchi
2019-01-11 8:04 ` Eli Zaretskii
2019-01-11 20:21 ` Simon Marchi
[not found] ` <83y37qgail.fsf@gnu.org>
2019-01-12 17:01 ` Tom Tromey [this message]
2019-01-13 5:09 ` Simon Marchi
2019-01-13 15:32 ` Eli Zaretskii
2019-01-13 16:17 ` Simon Marchi
2019-01-13 16:49 ` Eli Zaretskii
2019-01-14 21:05 ` Simon Marchi
2019-01-11 12:34 ` Andrew Burgess
2019-01-11 18:39 ` Pedro Alves
2019-01-11 23:36 ` Simon Marchi
2019-01-12 1:40 ` Andrew Burgess
2019-01-12 16:54 ` Tom Tromey
2019-01-13 5:49 ` Simon Marchi
2019-01-11 21:07 ` Simon Marchi
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=87pnt1vmhr.fsf@tromey.com \
--to=tom@tromey.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=simon.marchi@ericsson.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