From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4446 invoked by alias); 29 Mar 2012 15:00:17 -0000 Received: (qmail 4390 invoked by uid 22791); 29 Mar 2012 15:00:13 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,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; Thu, 29 Mar 2012 15:00: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 q2TExvMg008579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Mar 2012 10:59:57 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q2TExtsU032178; Thu, 29 Mar 2012 10:59:56 -0400 Message-ID: <4F7478EB.7060709@redhat.com> Date: Thu, 29 Mar 2012 15:00:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120316 Thunderbird/11.0 MIME-Version: 1.0 To: Hui Zhu CC: gdb-patches@sourceware.org Subject: Re: [PATCH] testsuite tfind.exp: If current target don't support trace, try gdbserver. References: <4F7428BD.30408@mentor.com> <4F742A2A.9060500@redhat.com> <4F742B75.3000408@mentor.com> <4F742F7D.1070602@redhat.com> <4F746B2A.6000302@mentor.com> <4F746DF3.5040500@redhat.com> <4F747005.8070109@mentor.com> <4F7470E7.7030001@redhat.com> <4F7473ED.6070007@mentor.com> <4F747435.1040805@redhat.com> <4F74750F.80006@mentor.com> In-Reply-To: <4F74750F.80006@mentor.com> Content-Type: text/plain; charset=ISO-8859-1 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-03/txt/msg00999.txt.bz2 On 03/29/2012 03:43 PM, Hui Zhu wrote: > That is back to the old question I ask for, right? :) > > Why the way try to make the trace function of GDB more easy be tested is not you want. > > And this way didn't affect current test. We're going in circles. I already explained why. But let me try one last time. We spawn the testsuite against a given target. It's wrong to run _some_ tests against _yet another_ target if not that first one. The gdb.server/ tests are special, and most scheduled for removal, exactly due to this issue. The trace function of GDB is not special compared to any other feature not supported by the native debugger. If you spawn a test run to test the native debugger, that's all that should be tested, with the features it doesn't support skipped. If you spawn a test run to test the sim, that's all that should be tested, with the features it doesn't support skipped. If you spawn a test run to test a remote qemu, that's all that should be tested, with the features it doesn't support skipped. If you spawn a test run to test a gdbserver, that's all that should be tested, with the features it doesn't support skipped. People should already be testing routinely against both the native target, and gdbserver. So the benefits of leaving the test run to test the target that it is meant to test should be obvious. So, no, I'll strongly object to such patches. Another example, imagine if native debugging already supported tracing, but then some patch inadvertently broke that, but then the test harness spawns gdbserver when the native target says "sorry I can't to tracing", and the test runs against gdbserver instead. You'd be masking the bug... If you want to make things easier, make it simpler to run the testsuite against the just built gdbserver, without having to install the native-gdbserver.exp (and friends) board files elsewhere, for example, with a new makefile target ('make check-gdbserver' or some such), that points SITE at an site.exp in the GDB source tree, that picks up the board files under src/gdb/testsuite/boards. -- Pedro Alves