From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13690 invoked by alias); 23 Apr 2010 16:41:42 -0000 Received: (qmail 13676 invoked by uid 22791); 23 Apr 2010 16:41:40 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Apr 2010 16:41:34 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o3NGfUlG065593 for ; Fri, 23 Apr 2010 18:41:30 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402:d::11]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id o3NGfUK6099838 for ; Fri, 23 Apr 2010 18:41:30 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o3NGfS9i063418 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 Apr 2010 18:41:30 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: Subject: [RFA] Testcase for bug report 11531 Date: Fri, 23 Apr 2010 16:41:00 -0000 Message-ID: <000301cae303$d6d068b0$84713a10$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: 2010-04/txt/msg00803.txt.bz2 Test case for the newly discovered problem with the old CANNOT_STEP_HW_WATCHPOINTS macro for recent Solaris. This leads to two failures on current x86_64-pc-solaris-2.11 (none of x86_64-pc-linux) that disappear if I undefined the macro. Is it possible to commit this first or should we first find a way to solve the problem? I could add a single line diff that would remove the macro definition in config/i386/nm-i386-sol2.h. The other question after is what to do with the code and comments related to CANNOT_STEP_HW_WATCHPOINTS macro in infrun.c source. Pierre Muller Pascal language support maintainer for GDB 2010-04-23 Pierre Muller PR breakpoints/11531. * testsuite/gdb.base/gdb11531.c: New file. * testsuite/gdb.base/gdb11531.exp: New file. Index: src/gdb/testsuite/gdb.base/gdb11531.c =================================================================== RCS file: testsuite/gdb.base/gdb11531.c diff -N testsuite/gdb.base/gdb11531.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ src/gdb/testsuite/gdb.base/gdb11531.c 23 Apr 2010 16:17:25 -0000 @@ -0,0 +1,40 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2010 Free Software Foundation, Inc. + + Contributed by Pierre Muller. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . + + Test for Solaris specific watchpoint problem. */ + +struct rec +{ + int x; + double y; + int z; +}; + +static struct rec myrec; + +int +main () +{ + myrec.x = 5; + myrec.y = 3.4; + myrec.z = 56; + myrec.x = 78; + return myrec.x; +} + Index: src/gdb/testsuite/gdb.base/gdb11531.exp =================================================================== RCS file: testsuite/gdb.base/gdb11531.exp diff -N testsuite/gdb.base/gdb11531.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ src/gdb/testsuite/gdb.base/gdb11531.exp 23 Apr 2010 16:17:25 -0000 @@ -0,0 +1,59 @@ +# This testcase is part of GDB, the GNU debugger. + +# Copyright 2010 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +# Test GDB for Solaris specific watchpoint problem. + +if $tracelevel then { + strace $tracelevel +} + +set prms_id 0 +set bug_id 0 + +set testfile "gdb11531" + +if { [prepare_for_testing $testfile.exp $testfile $testfile.c {debug}] } { + return -1; +} + + +# Do not use run_to main +# as this sets a breakpoint at main. +# 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. + +gdb_test "start" ".*Temporary breakpoint.*" + +gdb_test "watch myrec.x" ".*atchpoint \[0-9\]+: myrec\.x" "Set watchpoint " + +gdb_test "next" \ + "Old value = 0.*New value = 5.*" \ + "watchpoint variable triggers at next" + +gdb_test "continue" \ + "Old value = .*New value = 78.*" \ + "watchpoint variable triggers at continue" + +gdb_test "continue" ".*Program exited.*" "Continue to program exit" + +gdb_test "start" "" "restart" + +gdb_test "next" "Old value = 0.*New value = 5.*" "watchpoint triggers after second start" +