From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13719 invoked by alias); 18 Apr 2002 06:40:29 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13708 invoked from network); 18 Apr 2002 06:40:26 -0000 Received: from unknown (HELO d12lmsgate-3.de.ibm.com) (195.212.91.201) by sources.redhat.com with SMTP; 18 Apr 2002 06:40:26 -0000 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA84978; Thu, 18 Apr 2002 08:40:24 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3I6eKO133222; Thu, 18 Apr 2002 08:40:21 +0200 Importance: Normal Sensitivity: Subject: Re: gdb 5.2 removes the conditional breakpoints To: Andrew Cagney Cc: "H . J . Lu" , gdb@sources.redhat.com Message-ID: From: "Michael Veksler" Date: Wed, 17 Apr 2002 23:40:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00301.txt.bz2 This is a real problem. Your argument that "5,2 has been around for ~4 years" does not hold water, how many people have been using 5.2 ? The "many eyeballs" effect takes place only when you "release early, release often" and 4 years cycle is anything but "often". Now that you have a branch, people will start using it. Bugs will be spotted, some of them will be critical (SEGV), some will be very bad (an important gdb state gets reset upon restart) and others will be simply annoying (print syntax will not work the way it is supposed to). That's life. If you want to make gdb better, you'd have to do things that the gcc team does now: 1. Shorten development cycle (gcc's goal is 6 months, but , they'll probably need 8)/ 2. Fix regressions of a branch even if they have "been around for 4 years". 3. Fix bugs even if they are not yours (gcc-2.95.4 had a work-around for a glibc bug). I started 5.2 evaluation only a month ago. The first bug I noticed was that it crashed with SEGV every time (which I reported, and it got fixed). The second bug (few hours later), was this conditional breakpoint problem. This problem is very annoying in C++. Every condition with virtual functions gets removed (at least those that I tried). I did not report it, because I am only toying with migrating my code to Linux and doing it in my spare time. My product is libraries, so it is my responsibility to make sure my users/customers can debug the code. So if they are about to run it on Linux, I have to make sure they can use gdb comfortably. If important fixes (like this one) do not get applied, I'll have to maintain a fork of gdb. I do not get paid to maintain Free SW (or OSS), so I hate this option (my manager will probably hate this even more). My users will hate this also (who wants to use forked code?) Please apply this patch to 5.2 branch (or at least say what's wrong with the patch, so that it can be perfected, and applied). Michael Andrew Cagney on 18-04-2002 06:21:02 Please respond to Andrew Cagney To: "H . J . Lu" cc: Michael Veksler/Haifa/IBM@IBMIL, gdb@sources.redhat.com Subject: Re: gdb 5.2 removes the conditional breakpoints > On Wed, Apr 17, 2002 at 08:34:54PM -0400, Andrew Cagney wrote: > >> > >> > May I check it into gdb 5.2? > >> >> No. 5,2 is effectivly frozen. I've the README file to fix, that is it. >> > > > It works with gdb 4.17 and someone broke it in 5.x. How long does it > take to fix it? (looks under table, nope, no fire ...) H.J. This ``very bad regression from gdb 4,17'' that must be in 5,2 has been around for ~4 years now without anyone even thinking to report it! Perhaphs it isn't so bad after all :-) BTW, a real .exp testcase? Andrew