From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17331 invoked by alias); 21 Aug 2014 12:48:34 -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 17320 invoked by uid 89); 21 Aug 2014 12:48:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 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; Thu, 21 Aug 2014 12:48:31 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7LCmSFP015468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Aug 2014 08:48:28 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7LCmPPa011318; Thu, 21 Aug 2014 08:48:27 -0400 Message-ID: <53F5EA99.9060107@redhat.com> Date: Thu, 21 Aug 2014 12:48: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> <53F4A907.9080504@redhat.com> <53F57B66.1030602@codesourcery.com> In-Reply-To: <53F57B66.1030602@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-08/txt/msg00475.txt.bz2 On 08/21/2014 05:53 AM, Yao Qi wrote: > On 08/20/2014 09:56 PM, Pedro Alves wrote: >> > 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. > No, the workaround doesn't have such assumption. The trace file > generated by GDB with 1.1.0 has a faked packet, and the trace file can > be read by GDB with 1.1.1. Although the faked packet is not necessary, > it doesn't make any error. > > Since 1.1.2, babeltrace becomes more restrict on CTF, and starts to > complain the faked packet GDB adds. The code in GDB was written when > 1.1.0 was released, at that moment, nobody knows how 1.1.2 does. > Likewise, we don't know how does babeltrace behave in 2015. We > followed the CTF spec to generate CTF data, and ideally babeltrace of > any version can parse them. However, it is not surprise to me that > two implementations (producer and consumer) have different > understandings on some parts of the specification. Right. From your description, newer babeltrace rejects the workaround because it's more strict now, which I read as the workaround somehow knowingly violating the CTF spec, hence, the workaround assuming babeltrace or other CTF consumers would remain lax. The point was that CTF generated by a GDB with 1.1.0 wouldn't be readable by a GDB with 1.1.2, and vice-versa. If it remains in place, the assumption that we can infer whether a workaround will be necessary or usable from the babeltrace version that is used to build the producer GDB isn't strictly correct. But maybe "assumption" was a too strong word. (I hope you didn't feel I was pointing fingers at you or something. Certainly not intended!) >> > 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. >> > > Yeah, the patch isn't perfect. I am fine with your suggestion, and the > patch below removes the workaround. Alright, onward! Thanks. >>>> >> > 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? >> > > That is still too abstract to operate, IMO. Kind of just as abstract as the question. :-) The "benefit" is being able to take advantage of the library's features. The "burden" is the cost/effort required to use the library and workaround any issues it might have. When there are bugfix releases that postdate a given version, I think the effort to support the older unfixed version isn't so much worth it. The bugs have been fixed at the source, and we can simply require builders/integrators upgrade to the latest bugfix release (that's what bugfix/stable releases are for!). Thus, IMO, the existence of bugfix releases makes the burden of maintaining support for old unfixed versions outweigh the benefits, as we can alternatively just say "not our problem: build against the latest fixed version instead, please". > Subject: [PATCH] Remove workaround to libbabeltrace 1.1.0 issue This looks good to me. Thanks, Pedro Alves