From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114037 invoked by alias); 6 Jul 2018 14:43:54 -0000 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 Received: (qmail 114028 invoked by uid 89); 6 Jul 2018 14:43:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=credit X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Jul 2018 14:43:52 +0000 Received: by simark.ca (Postfix, from userid 112) id DB2871E52E; Fri, 6 Jul 2018 10:43:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=simark.ca; s=mail; t=1530888230; bh=da6YY3AEVxrM8w0qIOtMoqgl1Zf50kNmJCL2ZrTBI+U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hhQXG7dBalaNaokA3EfJD0go2MdnPOF84xpekXNQL2f1v75ANCd1WndZKEVpf1G/q tA/hPKbSTBASKFia6/LcmXuD8DBK+R5bSj2r1PTjA6WaODLXYWv7+trdYrmrJwbwK7 WxzKHyao0tkTlCoE5hNqw+t1R+8pCCwM/C7dMWKk= Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 336B01E08D; Fri, 6 Jul 2018 10:43:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=simark.ca; s=mail; t=1530888229; bh=da6YY3AEVxrM8w0qIOtMoqgl1Zf50kNmJCL2ZrTBI+U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Je0aw3K5sCs2wIt2JPfpLdJCYqxQi0x7kb9UaAHDItrlmKtC1jD+dUIIF709cO4Nr AXHM24NYqrWPvQk06zDIhbE76Cl0a4nOuPZGkwTAi2zg3s5QeGfZqKcX2spjroszlm YWAMAQb43mX2CpefhBxJk+jPi4SFPo3cHDY3LtsQ= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 06 Jul 2018 14:43:00 -0000 From: Simon Marchi To: Andrew Burgess Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/testsuite: Run test when software watchpoints are used In-Reply-To: <20180706135950.GM2675@embecosm.com> References: <20180704164017.5849-1-andrew.burgess@embecosm.com> <20180706135950.GM2675@embecosm.com> Message-ID: <25d43a27477e9ac14c7a0a4dad19d580@simark.ca> X-Sender: simark@simark.ca User-Agent: Roundcube Webmail/1.3.6 X-SW-Source: 2018-07/txt/msg00148.txt.bz2 On 2018-07-06 09:59, Andrew Burgess wrote: > I think you give me too much credit! > > What happened was I had a target without h/w watchpoints, I ran the > GDB testsuite and had a set of passes and fails. After some > investigation I realised that I'd neglected to mark the target as not > supporting h/w watchpoints in the board file. > > Once I'd added the no h/w watchpoint flag in the board file I reran > the tests, and mostly things looked better. Failures, or unresolved > tests had become unsupported. > > However.... in watchpoint-reuse-slot.exp a number of tests that used > to pass had gone away, so I went looking at the test script. > > What I saw was that though the test declared a need for h/w > watchpoints, the test would run perfectly fine without them. > > You'll notice that with my change if the board file says that h/w > watchpoints are supported then we still look for the full "Hardware > watchpoint" pattern in the output, that is, my change does not mean > that if GDB broke and h/w watchpoints changed to s/w watchpoints (when > they shouldn't) the test would pass. I think that after my change all > targets that previously ran this test are just as well tested as they > ever were. > > But, we have additional s/w watchpoint testing for targets that don't > support h/w watchpoints. Is this testing anything that's not covered > elsewhere? Honestly, I don't know. There probably is a lot of test > duplication, but I can't guarantee that there's nothing unique in > here. > > I guess my question is, what's the harm from broadening the test in > this way? If I've missed something and this change could mean a bug > can now slip into GDB then absolutely, this is not acceptable. But, I > can't see how (yet)... Indeed, I see no harm in running more tests, at worst it's useless. Maybe it will find some bug in the software watchpoint code. I was thinking that we might as well run it with software watchpoints even with targets that support hardware watchpoints. We could run unconditionally with "set can-use-hw-watchpoints 0" and run it with "1" on targets that support hw watchpoints. Simon