From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110451 invoked by alias); 13 Jan 2019 15:32:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 110425 invoked by uid 89); 13 Jan 2019 15:32:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=knew, readers, prevent X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 13 Jan 2019 15:32:34 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56353) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gihkV-0005MS-J2; Sun, 13 Jan 2019 10:32:31 -0500 Received: from [176.228.60.248] (port=2140 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gihkV-0004ik-6m; Sun, 13 Jan 2019 10:32:31 -0500 Date: Sun, 13 Jan 2019 15:32:00 -0000 Message-Id: <83r2dgefpc.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi CC: gdb-patches@sourceware.org, palves@redhat.com In-reply-to: <10a03370-3f18-a716-eaca-5da6621d1660@ericsson.com> (message from Simon Marchi on Sun, 13 Jan 2019 05:09:29 +0000) Subject: Re: [PATCH] Fix MI output for multi-location breakpoints References: <20190111001516.4761-1-simon.marchi@ericsson.com> <83lg3rhb6r.fsf@gnu.org> <7cf31d37-3931-bbac-07f2-c61f57be142c@ericsson.com> <83y37qgail.fsf@gnu.org> <10a03370-3f18-a716-eaca-5da6621d1660@ericsson.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00313.txt.bz2 > From: Simon Marchi > CC: "gdb-patches@sourceware.org" , > "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.