From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2791 invoked by alias); 23 Apr 2010 07:42:48 -0000 Received: (qmail 2768 invoked by uid 22791); 23 Apr 2010 07:42:42 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.altenpts.nl (HELO mail.altenpts.nl) (195.86.56.45) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Apr 2010 07:42:31 +0000 Received: from [11.0.0.159] ([11.0.0.159]) by mail.altenpts.nl; Fri, 23 Apr 2010 09:41:50 +0200 To: "Joel Brobecker" , "Pierre Muller" Cc: Peter.Schauer@regent.e-technik.tu-muenchen.de, gdb@sourceware.org, "'Joseph S. Myers'" , "'Pedro Alves'" From: "Pieter Maljaars" Reply-To: pieter.maljaars@altenpts.nl Subject: Re: Question about solaris CANNOT_STEP_HW_WATCHPOINTS macro In-Reply-To: 20100422235956.GG13204@adacore.com Message-ID: <20100423074150.24ae59af@mail.altenpts.nl> Date: Fri, 23 Apr 2010 07:42:00 -0000 X-User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.17) Gecko/2010010604 Ubuntu/8.10 (intrepid) Firefox/3.0.17 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00092.txt.bz2 > Looks like a different bug is now occurring: > > (gdb) start > Temporary breakpoint 1 at 0x805067a: file foo.c, line 13. > Starting program: [...]/foo > > Temporary breakpoint 1, main () at foo.c:13 > 13 myrec.x = 5; > (gdb) print myrec.x > $1 = 0 > (gdb) watch myrec.x > Hardware watchpoint 2: myrec.x > (gdb) s > 14 myrec.y = 3.4; I have tested this with Solaris 2.10 and GDB-7.1. I have removed the CANNOT_STEP_HW_WATCHPOINT define. Here this bug does not occur. (gdb) start Temporary breakpoint 1 at 0x8050681: file watchp.c, line 13. Starting program: [...]/watchp Temporary breakpoint 1, main () at watchp.c:13 13 myrec.x = 5; (gdb) print myrec.x $1 = 0 (gdb) watch myrec.x Hardware watchpoint 2: myrec.x (gdb) s Hardware watchpoint 2: myrec.x Old value = 0 New value = 5 main () at watchp.c:14 14 myrec.y = 3.4; Here it works as expected. GDB stops also at the other watchpoint. So with "step" and "continue" both watchpoints are triggered, like it behaves on x86-linux. Pieter Maljaars