From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22395 invoked by alias); 13 Sep 2003 00:17:45 -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 22387 invoked from network); 13 Sep 2003 00:17:44 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 13 Sep 2003 00:17:44 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.9/8.12.9) with ESMTP id h8D0Hg9Q016244; Fri, 12 Sep 2003 19:17:42 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h8D0HgHK028924; Fri, 12 Sep 2003 19:17:42 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.9/8.12.9/Submit) id h8D0HgJl028923; Fri, 12 Sep 2003 20:17:42 -0400 Date: Sat, 13 Sep 2003 00:17:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200309130017.h8D0HgJl028923@duracef.shout.net> To: cgf@redhat.com Subject: Re: gcc HEAD bad stabs (?) Cc: gdb@sources.redhat.com X-SW-Source: 2003-09/txt/msg00176.txt.bz2 cgf> Hmm. Have you considered sending email with a subject like "The cgf> continual degradation of stabs with gcc" or something like that? cgf> I'd do it but then someone would ask for details... Well, gcc has a process in place: I file P1 bugs, I mark them as "[3.4 regression]", Mark Mitchell in his capacity as release manager tracks all the regression bugs. We can't really make other people fix bugs. Look to our own house; the number of open gdb bugs goes up and up and up. When the season comes to cut the 3.4 branch I will complain if there are ANY open debug info regressions at that time. But they are months away from cutting their branch. I think we just have to suck it up and accept that gcc HEAD is dangerously unstable, and keep filing regression bugs. It's dangerous for anybody to ship a compiler out of gcc HEAD! The gcc 3.3 branch is healthy and I haven't had trouble with it in the test bed. Another thing gdb can do is fix some of our tests that fluctuate from run to run, so that it's easier to tell people "run the gdb test suite before and after and compare the results". And contribute to Dan Kegel's crossgcc project so that it does crossgdb as well. Michael C