From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17396 invoked by alias); 5 Feb 2003 22:41:19 -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 17389 invoked from network); 5 Feb 2003 22:41:19 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 172.16.49.205 with SMTP; 5 Feb 2003 22:41:19 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h15Mets11922; Wed, 5 Feb 2003 16:40:55 -0600 Date: Wed, 05 Feb 2003 22:41:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200302052240.h15Mets11922@duracef.shout.net> To: jimb@redhat.com Subject: Re: Clean up gdb.c++ tests for dwarf 1 Cc: carlton@math.stanford.edu, fnasser@redhat.com, gdb@sources.redhat.com X-SW-Source: 2003-02/txt/msg00117.txt.bz2 Jim B posits: > Your rationale here is that, since we don't really know which of these > failures are genuine, can't-be-done-with-Dwarf-1 expected failures, > and which are GDB bugs, you want to dump them all into the "genuine > bug" category and start re-categorizing, using our modern > interpretation of XFAIL and KFAIL? You could interpret plan (1) that way. Consider the scenario where someone is still testing gdb with DWARF 1. They are getting a mixture of FAIL's and XFAIL's now. After plan (1), they will get a lot more FAIL's and a lot less XFAIL's. There is a lot of bit rot and lies in the test suite. If my task were to evaluate c++ support with DWARF 1, then I would *start* by assuming that all the XFAIL's are lying about the "X" part, and I would treat them the same as FAIL's anyways. So that corresponds to what you said. Of course I am hoping that after I dump them all into the 'genuine bug' category, that they will sit there until DWARF 1 is obsolete and removed, and no one will ever have to 'start re-categorizing'. But someone can do that if they need to. Michael C