From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35058 invoked by alias); 22 Apr 2015 21:13:48 -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 35040 invoked by uid 89); 22 Apr 2015 21:13:44 -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; Wed, 22 Apr 2015 21:13:43 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 69684A0E4A for ; Wed, 22 Apr 2015 21:13:42 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-19.ams2.redhat.com [10.36.112.19]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3MLDeIK013554; Wed, 22 Apr 2015 17:13:41 -0400 Message-ID: <55380F04.9050909@redhat.com> Date: Wed, 22 Apr 2015 21:13:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: [PATCH] compile: Use libcc1.so->libcc1.so.0 References: <20150421213616.14023.38329.stgit@host1.jankratochvil.net> In-Reply-To: <20150421213616.14023.38329.stgit@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00848.txt.bz2 On 21/04/15 22:36, Jan Kratochvil wrote: > Hi, > > the next [patch 3/4] will change the libcc1.so API. I am not sure if it gets > approved in GCC land but for such case: > (1) We really need to change GCC_FE_VERSION_0 -> GCC_FE_VERSION_1, this > feature is there for this purpose. That is [patch 2/4]. > (2) Currently GDB does only dlopen("libcc1.so") and then depending on which > libcc1.so version it would find first it would succeed/fail. > I guess it is more convenient to do dlopen("libcc1.so.1") instead > (where ".1"=".x" corresponds to GCC_FE_VERSION_x). > That is this patch (with x=0). > (3) Currently there is no backward or forward compatibility although there > could be one implemented. Personally I think the 'compile' feature is > still in experimental stage so that it is OK to require last releases. > At least in Fedora we can keep GDB<->GCC in sync. > > Will this mean that the next release of GDB will require GCC 5.0.1 (or whatever the next version of GCC after 5.0)? If so, then, I object. This could mean many months of GDB and GCC releases not coinciding and no functionality being present. If not, how does GDB work with an older GCC? It also does not seem a good thing to change the API before GCC 5.0 is even released. I think as far as possible we want to be fault tolerant with GCC. Another solution is to add another method to the end of the vtable of functions presented to GDB from the GCC plugin, and save API changes for more synchronized and planned changes. Cheers Phil