From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21000 invoked by alias); 20 Aug 2014 13:56:33 -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 20963 invoked by uid 89); 20 Aug 2014 13:56:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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, 20 Aug 2014 13:56:30 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7KDuPvl027818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Aug 2014 09:56:26 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7KDuNbS018952; Wed, 20 Aug 2014 09:56:24 -0400 Message-ID: <53F4A907.9080504@redhat.com> Date: Wed, 20 Aug 2014 13:56:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yao Qi , Jan Kratochvil CC: "gdb-patches@sourceware.org" Subject: Re: --with-babeltrace generates many FAILs References: <20140816204614.GA7000@host2.jankratochvil.net> <53F3457E.5030205@codesourcery.com> <20140819140755.GA30208@host2.jankratochvil.net> <53F41DE5.1010406@codesourcery.com> <53F46D48.2060200@redhat.com> <53F487AC.7070606@codesourcery.com> In-Reply-To: <53F487AC.7070606@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-08/txt/msg00401.txt.bz2 On 08/20/2014 12:34 PM, Yao Qi wrote: > On 08/20/2014 05:41 PM, Pedro Alves wrote: >> As there's been fixed babeltrace versions for a while, I'd go with >> simply dropping the workaround, and have integrators build newer >> GDB with newer babeltrace. I suppose we have a testcase in our >> testsuite that fails if we remove the workaround and GDB is built with >> broken babeltrace? That should let the integrator know that it's >> building again a broken lib. > > Yes, we have such test case, such as actions.exp, at least. Without > the workaround, GDB with libbabeltrace 1.1.0 will fail in actions.exp. > However, is it a good idea that let test failure signal a wrong version > lib is used? IMO, in this case, it's sufficient. There are point releases that fix the issue, which are supposedly compatible with 1.1.0 -- updating those is just a normal maintenance issue, doesn't involve any sort of porting in gdb, etc. > I am not sure. It is the configure's job to check whether > the library is wrong or broken. Note that there's a fundamental issue with the workaround -- it assumes that the gdb that generates CTF is the same that consumes it. It's certainly easy to imagine a CTF file generated by a gdb not affected by the bug be consumed by a gdb with the bug. Or the other way around. >> IOW, why do we still need to support 1.1.0? > > No special reason, 1.1.0 was just used when I did the CTF work in GDB, > and was used on my laptop since then. IIRC, 1.1.0 was released in 2013 > March, so it isn't very old and it might be used somewhere. > Shouldn't we be conservative in this case? My point is exactly that this is new-ish code, and a moving target. If bugs are fixed promptly, why go through trouble working around them in gdb instead of just updating the version in the distro? It'd be different if we were talking about a one liner instead of a good chunk of autoconf/pkg-config glue. I'm not strictly objecting your patch, but it does look like the kind of code that: #1 will need further tweaking in the future; #2 will become obsolete anyway as time passes anyway. Couple that with the generator != consumer issue, and it raises eyebrows. > In general, GDB and GDBserver uses a set of libraries, what are the > criteria of > > 1. stop supporting a version of a library, such as libbabeltrace 1.1.0 When the burden of supporting it outweighs the benefits? > 2. stop supporting or using a library, such as the UST stuff in GDBserver, When nobody wants to maintain it anymore (I personally don't)? Thanks, Pedro Alves