From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1413 invoked by alias); 30 Apr 2012 19:06:54 -0000 Received: (qmail 1397 invoked by uid 22791); 30 Apr 2012 19:06:53 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Mon, 30 Apr 2012 19:05:54 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3UJ5oun005379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 15:05:50 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q3UJ5njr012679; Mon, 30 Apr 2012 15:05:49 -0400 Message-ID: <4F9EE28C.6010505@redhat.com> Date: Mon, 30 Apr 2012 19:17:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jeff Kenton CC: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH] Add support for Tilera TILE-Gx processor (part 2/2: gdb) References: <4F9066C5.30501@tilera.com> <4F917C1F.3060804@codesourcery.com> <4F917F7F.9030601@tilera.com> <4F9EDD4B.3020409@redhat.com> <4F9EDF47.1080904@tilera.com> In-Reply-To: <4F9EDF47.1080904@tilera.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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-04/txt/msg01087.txt.bz2 On 04/30/2012 07:51 PM, Jeff Kenton wrote: > On 04/30/2012 02:43 PM, Pedro Alves wrote: >> I meant to reply to this before, but it slipped... >> >> On 04/20/2012 04:23 PM, Jeff Kenton wrote: >> >> === gdb Summary === >> >> # of expected passes 18181 >> # of unexpected failures 625 >> >> Did you look at what is causing these hundreds of failures? Although there >> are thousands of passes, such high failure rate is usually indicative of >> something badly borked. You'd be surprised at how far in testsuite results >> you can get with a gdb that manages to loads programs, but is a brick >> at actually debugging live programs ... >> >>> # of expected failures 100 >>> # of known failures 59 >>> # of untested testcases 12 >>> # of unresolved testcases 4 >>> # of unsupported tests 118 >>> /gdb_tests/gdb/build/gdb/testsuite/../../gdb/gdb version 7.4.50.20120410 -nw -nx -data-directory /gdb_tests/gdb/build/gdb/testsuite/../data-directory >> > > We use it on production systems, so lots of things work. Checking the failures is on my list of things to do. Is there a target failure threshhold we need to hit before our GDB is accepted, or can we submit what we have (with the fixes you specified) and work on the remaining test suite failures afterwards? There's no threshold, and certainly zero fails are not expected. Not even the most maintained ports get that far, unfortunately. So we'll accept the port anyway. But I'd be happier if at least you had browsed the gdb.sum/gdb.log for obvious issues, and at least (any) internal-errors that show up are given some consideration. -- Pedro Alves