Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Simon Marchi <simon.marchi@ericsson.com>
Cc: gdb-patches@sourceware.org, palves@redhat.com
Subject: Re: [PATCH] Fix MI output for multi-location breakpoints
Date: Sun, 13 Jan 2019 15:32:00 -0000	[thread overview]
Message-ID: <83r2dgefpc.fsf@gnu.org> (raw)
In-Reply-To: <10a03370-3f18-a716-eaca-5da6621d1660@ericsson.com> (message from	Simon Marchi on Sun, 13 Jan 2019 05:09:29 +0000)

> From: Simon Marchi <simon.marchi@ericsson.com>
> CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
> 	"palves@redhat.com" <palves@redhat.com>
> Date: Sun, 13 Jan 2019 05:09:29 +0000
> 
> > People read newer manuals even if they have older versions of GDB
> > available.  E.g., I have on my development system all the versions of
> > GDB since v6.3, but only one version of the manual, the latest one.
> > Since Texinfo doesn't provide a way of installing several versions of
> > the same manual side by side, we should assume that my situation is
> > quite typical.
> > 
> > So let's not assume that when one reads a manual for GDB X.Y they are
> > interested only in that GDB version.
> 
> But we could say that for every single feature.  We introduced (or rather, will
> introduce) "set index-cache" in GDB 8.3, and we don't mention in the doc that it
> exists since 8.3.

Doing this for every single feature is indeed overkill.  But changes
in the version of MI are rare and backward-incompatible, so they are a
different story, IMO.

> > I'm okay with adding a detailed table elsewhere, but I don't think
> > it's a good idea to remove the above information from the description
> > of the -mi command-line switch.
> 
> Would a cross-reference to the table be good enough?

Not in this particular case, no.

> If we add a detailed table
> of MI versions (which I think is required), we will have the information about which
> GDB version introduced each MI versions at three separate places in the manual...

Which is the third place?  I thought we have it only in two places.
The detailed table could come instead of that second place we have
now, not in addition to it.  But let's wait with that decision until
we actually see the proposed change for that table.

> - mi1 can be used by any GDB version between 5.1 and the present.  Why do we list
>   specifically 5.1, 5.2 and 5.3?

So that readers who have those versions installed knew they can only
use mi1.

> - The term "included in", or "used by", regardless of whether it is coupled with "5.1"
>   or 5.1, 5.2 and 5.3".  Since mi1 can be used with any version between 5.1 and the
>   latest release, I think we should be looking for a phrasing that conveys that it's
>   an half-open interval.  Saying that "mi1 is used by GDB 5.1" just tells you about
>   5.1.  Saying that "mi1 is available starting with GDB 5.1" tells you about all
>   versions between 5.1 and the current one.

The purpose of that text is to say that those versions can only use
mi1.

> > That's not what bothered me.  What bothered me was that we released a
> > GDB with this MI syntax without fixing it first.  I'm wondering how to
> > prevent such mistakes in the future.
> 
> The problem here is that we had a tuple without name/id in a context where this
> should be forbidden.  Maybe we could add some assert in ui_out::begin to catch
> this.

Something that enforces our own syntax rules would be nice, indeed.

> Instead of matching the MI output textually, we should have a proper MI output parser
> written in TCL.  This would mean that any output produced by GDB in MI could be ran
> through this parser, and any non-conforming output would cause an error.

Something like that, yes.

Thanks.


  reply	other threads:[~2019-01-13 15:32 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
2019-01-13  5:09       ` Simon Marchi
2019-01-13 15:32         ` Eli Zaretskii [this message]
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=83r2dgefpc.fsf@gnu.org \
    --to=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