From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7162 invoked by alias); 3 Dec 2003 05:25:23 -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 7154 invoked from network); 3 Dec 2003 05:25:22 -0000 Received: from unknown (HELO blount.mail.mindspring.net) (207.69.200.226) by sources.redhat.com with SMTP; 3 Dec 2003 05:25:22 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1ARPVL-0008Au-00; Wed, 03 Dec 2003 00:24:51 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id DF66E4B35B; Wed, 3 Dec 2003 00:24:45 -0500 (EST) To: cagney@gnu.org, fnf@ninemoons.com Subject: Re: [PATCH] use "verbose" for notification of not running a test Cc: drow@mvista.com, gdb-patches@sources.redhat.com Message-Id: <20031203052445.DF66E4B35B@berman.michael-chastain.com> Date: Wed, 03 Dec 2003 05:25:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2003-12/txt/msg00076.txt.bz2 > gdb.arch/altivec-abi.exp: verbose "Skipping altivec abi tests." > gdb.arch/altivec-regs.exp: verbose "Skipping altivec register tests." > gdb.arch/e500-abi.exp: verbose "Skipping e500 abi tests." > gdb.arch/e500-regs.exp: verbose "Skipping e500 register tests." > gdb.arch/gdb1291.exp: verbose "Skipping SH backtrace tests." > gdb.arch/gdb1431.exp: verbose "Skipping SH backtrace tests." > gdb.arch/i386-prologue.exp: verbose "Skipping i386 prologue tests." > gdb.arch/i386-unwind.exp: verbose "Skipping i386 unwinder tests." Hmmm. These are all conditioned on target architecture. My first reaction is that it's good to have arch-specific tests. It would be silly to pretend that gdb has the same features on all architectures. It's a debugger, not a web server or a text editor! My second reaction is that when I run an sh-*-* test on native i686-pc-linux-gnu, I don't need to see an UNSUPPORTED about it. So the existing "verbose ... / return" works for me. > gdb.base/a2-run.exp: verbose "Skipping a2-run.exp because of noargs." Yes, I think this is a good place for UNSUPPORTED. "noargs" is either a limitation of the test environment or of the toolchain. If it's a limitation of the test environment, I think that UNSUPPORTED matches it. If it's a limitation of the toolchain, then it's actually a bit of a cheat to set "noargs", but UNSUPPORTED would not be too bad. A casual look at dejagnu/baseboards.exp and "noargs" makes me think that "noargs" is generally a property of the test board, not a property of the toolchain. The dejagnu doco says: UNSUPPORTED A test depends on a conditionally available feature that does not exist (in the configured testing environment). For example, you can use this outcome to report on a test case that does not work on a particular target because its operating system support does not include a required subroutine. To me, the things in gdb.arch are not "conditionally available" on non-matching targets; they are just plain unavailable. And if the limit is in the toolchain rather than the testing environment, it is really a FAIL, not an UNSUPPORTED. UNIMPLEMENTED would be more accurate but there is no such word, so I'm not too hurt by fudging UNSUPPORTED to mean "unsupported by the toolchain" as well as "unsupported by the test environment" from time to time. What do other people think? Michael C