This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix MI output for multi-location breakpoints


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]