From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17620 invoked by alias); 2 Jan 2003 19:58:36 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17599 invoked from network); 2 Jan 2003 19:58:35 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 2 Jan 2003 19:58:35 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h02JV6B19533 for ; Thu, 2 Jan 2003 14:31:07 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h02JwGn27973; Thu, 2 Jan 2003 14:58:16 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h02JwEn18571; Thu, 2 Jan 2003 11:58:14 -0800 Message-ID: <3E1499D6.7A648DBC@redhat.com> Date: Thu, 02 Jan 2003 19:58:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Michael Elizabeth Chastain CC: drow@mvista.com, gdb-patches@sources.redhat.com Subject: Re: [RFA/testsuite] Suppress errors building thread tests References: <200212311902.gBVJ23j24532@duracef.shout.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00017.txt.bz2 Michael Elizabeth Chastain wrote: > > Recommended for self-approval by Daniel J. > > Proofread and tested. All the pthreads library noise is gone > from gdb.sum. The results for gcore-thread.exp, print-threads.exp, > and schedlock.exp are fine. > > > Note the use of gdb_suppress_entire_file. I'm just doing that because it's > > what the other tests do; I really dislike gdb_suppress_entire_file, so I > > think I may send along a followup patch to change it to a "return -1". > > gdb_compile_pthreads already does an "unsupported" if compilation fails. If > > we can't build the threads tests, there's no point in FAILing them, in my > > opinion; this clutters up results when I run simulator testing. Thoughts? > > I'm with you. If compilation+linking fails, I am fine with one > UNSUPPORTED per test script. It would be even better if the UNSUPPORTED's > come from a known unsupported list rather than dynamic conditions. > > Michael C Ditto. Michael S.