From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23248 invoked by alias); 24 Aug 2012 17:12:25 -0000 Received: (qmail 23236 invoked by uid 22791); 24 Aug 2012 17:12:23 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Aug 2012 17:12:01 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7OHBx2p008352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Aug 2012 13:11:59 -0400 Received: from host2.jankratochvil.net (ovpn-116-37.ams2.redhat.com [10.36.116.37]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q7OHBsp5009076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Aug 2012 13:11:57 -0400 Date: Fri, 24 Aug 2012 17:12:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH 2/2] Remove pass in skip_unwinder_tests Message-ID: <20120824171141.GA12644@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5037B259.2040206@redhat.com> <5037B15E.1020809@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-08/txt/msg00751.txt.bz2 On Fri, 24 Aug 2012 18:52:46 +0200, Pedro Alves wrote: > On 08/24/2012 05:18 PM, Jan Kratochvil wrote: > > If the system does not have unwinder hook it will XFAIL. XFAIL is not even > > displayed on screen during interactive run. > > That's not what an XFAIL is for. XFAIL is when you do > "print 2+2", you expect "4" to come out, but you know that on > some broken systems instead "5" comes out, so you XFAIL on those systems, > as in, to fix that _wrong result_, you need to fix something else, not GDB, > but there _is_ something broken that should be fixed. Exactly. This problem is in libgcc and GDB cannot fix it, so it is is XFAIL. > The fact is that the check for the unwinder hook actually _succeeded_. > It just happened that the result of the successful test was > "no unwinder hook". This is a matter of opinion how one should look at it. In your way you can PASS everything because DejaGNU _succeeded_, just GDB returned wrong result. > I don't believe this support check should XFAIL on not-top-of-tree-glibc, This is about gcc, not about glibc. > just like they shouldn't trigger an XFAIL on Windows or Solaris (if it > ever runs there). They should, in the point of view I wrote the testcase. > Rather, this is why DejaGNU has UNSUPPORTED -- it also > leaves a line in the .sum file, and is also not displayed on screen during > interactive run (IIUYC). If testing for the presence of the unwinder hooks > fails (as in, we get some unexpected output, like an internal error), then > we should be issuing in addition an UNRESOLVED instead of UNSUPPORTED > (we don't do that presently): But we perfectly understand thy the unwinder hook is missing there, in former versions of libgcc the hook just was not there. There is nothing to investigate on those old libraries. > "Declares a test to have an unresolved outcome. unresolved writes in the log file a > message beginning with `UNRESOLVED', appending the argument string. This usually means > the test did not execute as expected, and a human being must go over results to > determine if it passed or failed (and to improve the test case). " I am aware of these DejaGNU results descriptions. I read them many times and I never understood where exactly are the differences between all of xfail/unsupported/untested/unresolved. So I no longer try to. I created some model of how testcases should be written. Apparently you have created your model. Any of such models should be wrritten down and GDB should stick to it. I really do not mind which one. > In isolation, it's mildly worse, because you can't tell whether > it's a regression, or a new failure. I spend sometimes hours of time evaluating GDB testsuite results daily, sorry but after the years I am too well aware what I find easier to evaluate. > "some system with broken system libraries or kernel, or some such". If it > were a GDB bug that only triggers on some systems, but still a GDB bug, it > would be a KFAIL. Yes, exactly. Regards, Jan