From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105171 invoked by alias); 12 Jan 2019 16:54:45 -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 105151 invoked by uid 89); 12 Jan 2019 16:54:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=accepting, life X-HELO: gateway22.websitewelcome.com Received: from gateway22.websitewelcome.com (HELO gateway22.websitewelcome.com) (192.185.47.144) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 12 Jan 2019 16:54:43 +0000 Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway22.websitewelcome.com (Postfix) with ESMTP id 303BC6091 for ; Sat, 12 Jan 2019 10:54:42 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id iMYUgfjA22qH7iMYUgJuu9; Sat, 12 Jan 2019 10:54:42 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=fiJTcjIGMjhS7PJpmLcv6sPaaH9itmY15UdiortZZxQ=; b=vXtgeSSV6oDC98lcPgPJzWeLo7 P3PYAOuRcEObEAZCjG+B3doZzuvw3iVYXeo8jHUgQLm1EaIDzmG6hlGu9KpVnoJrQW/jPvSAH462l gmbhax5Q6GijaLrAWAdNuYywc; Received: from 75-166-72-210.hlrn.qwest.net ([75.166.72.210]:38222 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1giMYT-0029ke-Sp; Sat, 12 Jan 2019 10:54:41 -0600 From: Tom Tromey To: Andrew Burgess Cc: Simon Marchi , Pedro Alves , "gdb-patches\@sourceware.org" Subject: Re: [PATCH] Fix MI output for multi-location breakpoints References: <20190111001516.4761-1-simon.marchi@ericsson.com> <20190111123420.GI3456@embecosm.com> <5cdbc81d-5198-f592-c142-8768991c306a@redhat.com> <973aa853-7a1b-4f7a-fd09-b99698aa6363@ericsson.com> <20190112014028.GK3456@embecosm.com> Date: Sat, 12 Jan 2019 16:54:00 -0000 In-Reply-To: <20190112014028.GK3456@embecosm.com> (Andrew Burgess's message of "Sat, 12 Jan 2019 01:40:28 +0000") Message-ID: <87r2dhvmsv.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-01/txt/msg00287.txt.bz2 >>>>> "Andrew" == Andrew Burgess writes: Andrew> Instead of adding a flag for this specific issue, should we consider Andrew> adding a generic mechanism that allows single commands to be run with Andrew> a different MI version? [...] Andrew> -break-insert --mi 3 LOCATION I tend to think the feature approach makes life easier for us and for front end developers when bumping MI versions. What I mean by this is that, if we ship MI3, then after some period of time -- probably several years, given gdb's conservative approach -- we'd like to remove MI2. This would let us clean up various hacks. But consider the current bug. The output is wrong in MI2, so a front end developer would send: -break-insert --mi 3 blah blah Now, we ship a gdb with, say, MI4. Now we either have to support backward compatibility here, and front ends will have to adapt whenever MI3 is dropped. With the feature flag, though, we can drop MI3 in this situation, but keep accepting -fix-bug-NNN commands, and up-to-date front ends can just keep working. I think the difference is that a feature flag has a ratchet effect: you can't go backward, only forward. Tom