From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97153 invoked by alias); 23 Apr 2015 10:53:01 -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 97135 invoked by uid 89); 23 Apr 2015 10:53:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 23 Apr 2015 10:53:00 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3NAqwVv012489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 23 Apr 2015 06:52:59 -0400 Received: from localhost.localdomain (ovpn-112-19.ams2.redhat.com [10.36.112.19]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3NAqvGc008278; Thu, 23 Apr 2015 06:52:57 -0400 Message-ID: <5538CF08.60801@redhat.com> Date: Thu, 23 Apr 2015 10:53:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Jan Kratochvil CC: gdb-patches@sourceware.org Subject: Re: [PATCH] compile: Use libcc1.so->libcc1.so.0 References: <20150421213616.14023.38329.stgit@host1.jankratochvil.net> <55380F04.9050909@redhat.com> <20150423052909.GA18986@host1.jankratochvil.net> In-Reply-To: <20150423052909.GA18986@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00862.txt.bz2 On 23/04/15 06:29, Jan Kratochvil wrote: > > So you request forward/backward compatibilities, specifically: > > (1) Do you request future gdb-7.10 is compatible with existing gcc-5.x? > > (2) Do you request future gcc-6.0 is compatible with existing gdb-7.9? > > With an answer for (1) and (2) we can decide on how to implement it. > > Both! ;) In principle the decision bump is OK; but, and this is the huge caveat, we could fix this quite easily by adding another method to the vtable exported by the plug-in and not need or require all of the tinkering that would be needed downstream. Yes, Fedora could be modified to cope with it, but we have to think about the work all the other distributions would also have to do if this proposed change were implemented. I don't think a version change merits that. And the change is tiny: just one more parameter for a function. You could avoid it by having two public methods exported in the vtable: foo (old params), foo (old params, new params) and then re-factoring out the old function to foo_worker_1 and have the two "foo" functions call foo_worker_1 with the new parameter or NULL in its place. I'm not adverse to version changes but I think they should merit the change. Possibly as a collection of changes. What are your thoughts? Cheers Phil