From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18511 invoked by alias); 25 Apr 2010 13:20:50 -0000 Received: (qmail 18480 invoked by uid 22791); 25 Apr 2010 13:20:48 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 25 Apr 2010 13:20:43 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0DC9E2BAC73; Sun, 25 Apr 2010 09:20:42 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZhDhkVTXEzXG; Sun, 25 Apr 2010 09:20:41 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C934B2BAC20; Sun, 25 Apr 2010 09:20:41 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 580FBF5896; Sun, 25 Apr 2010 09:20:41 -0400 (EDT) Date: Sun, 25 Apr 2010 13:20:00 -0000 From: Joel Brobecker To: Pierre Muller Cc: 'Pedro Alves' , gdb-patches@sourceware.org Subject: Re: [RFA- v2] Testcase for bug report 11531 and fix for Solaris Message-ID: <20100425132041.GA2732@adacore.com> References: <000301cae303$d6d068b0$84713a10$@muller@ics-cnrs.unistra.fr> <20100423172933.GO19194@adacore.com> <201004231915.49375.pedro@codesourcery.com> <002101cae3c0$a56276c0$f0276440$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002101cae3c0$a56276c0$f0276440$@muller@ics-cnrs.unistra.fr> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-04/txt/msg00837.txt.bz2 > PS1: Once this macro is removed, I will submit a RFA for the complete > removal of nm-i386-sol2.h. > PS2: The code inside infrun.c ought to be changed as well. If it is > now non-functional I propose to generate a compilation error if the > macro is still defined, this way third party users will not be > surprised that it does not work... Since nm-i386-sol2.h was the last user of the CANNOT_STEP_HW_WATCHPOINTS macro, we should just purge it entirely. We cannot worry about third parties that did not contribute their code (that includes people like me who still has lots of uncontributed code in the AdaCore version of GDB). > ChangeLog entry: > 2010-04-24 Pierre Muller > > * config/i386/nm-i386-sol2.h (CANNOT_STEP_HW_WATCHPOINTS): > Remove macro. As per the above, let's just purge the whole thing. You can, at your convinience, just delete the line from the nm file and do the rest of the purge separately, so do everything all in one patch. > testsuite/ChangeLog entry: > > PR breakpoints/11531. > * testsuite/gdb.base/gdb11531.c: New file. > * testsuite/gdb.base/gdb11531.exp: New file. > +# If the breakpoint is at the same instruction as the > +# watchpoint value assignment > +# you can fall into the problem of the stepping over the breakpoint > +# location that can also trigger a watchpoint miss > +# This is not the problem reported here. > +# Thus we remove all breakpoints first. Suggest a different wording: # The breakpoint is probably at the instruction where the value being # watched (myrec.x) gets updated. This is the instruction where we # expect to receive a watchpoint notification when we do the "stepi" # below. However, having the breakpoint at the same location as this # intruction can possibly interfere with our testcase, as stepping # over the breakpoint in order to get past it may incorrectly lead # to the debugger missing the watchpoint hit. This would be a bug # in GDB, but this is not the bug that we are trying to test here. # So, we remove all breakpoints first. > +gdb_test "stepi" \ > + "Old value = 0.*New value = 5.*" \ > + "watchpoint variable triggers at next" I would prefer that you would verify that the old value and new values match exactly. The wildcard matching prevents that, so the test would still pass even if the debugger printed that the new value was 51274793875. It seems that the use of a wildcard here is just a cheap way of matching a new-line sequence - the typical way of matching new-lines, I've found, is to use "\[\r\n\]+". It's been helpful to define a variable with a short name that contains that regexp and use that variable, rather than repeat manually the new-line regexp... > +gdb_test "start" "" "restart" > + > +gdb_test "next" "Old value = 0.*New value = 5.*" "watchpoint triggers after > second start" Can you explain the purpose of this part of the testcase. Again, the use of the start command in a gdb_test does not work with some configurations. -- Joel