From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31318 invoked by alias); 31 Dec 2002 19:02:18 -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 31311 invoked from network); 31 Dec 2002 19:02:17 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 209.249.29.67 with SMTP; 31 Dec 2002 19:02:17 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id gBVJ23j24532; Tue, 31 Dec 2002 13:02:03 -0600 Date: Tue, 31 Dec 2002 13:31:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200212311902.gBVJ23j24532@duracef.shout.net> To: drow@mvista.com, gdb-patches@sources.redhat.com Subject: Re: [RFA/testsuite] Suppress errors building thread tests X-SW-Source: 2002-12/txt/msg00770.txt.bz2 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 === 2002-12-31 Daniel Jacobowitz Fix PR gdb/844 * lib/gdb.exp (gdb_compile): Handle "quiet" option. (gdb_compile_pthreads): Pass "quiet" to gdb_compile. * gdb.threads/gcore-thread.exp: Use gdb_compile_pthreads. * gdb.threads/print-threads.exp: Likewise. * gdb.threads/schedlock.exp: Likewise.