From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2386 invoked by alias); 23 Apr 2010 12:42:43 -0000 Received: (qmail 2376 invoked by uid 22791); 23 Apr 2010 12:42:41 -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.151) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Apr 2010 12:42: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 o3NCelBn091521 ; Fri, 23 Apr 2010 14:40:47 +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 o3NCekdu067748 ; Fri, 23 Apr 2010 14:40:46 +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 o3NCejqJ078971 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 23 Apr 2010 14:40:46 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: , "'Joel Brobecker'" Cc: , , "'Joseph S. Myers'" , "'Pedro Alves'" References: 20100422235956.GG13204@adacore.com <20100423074150.24ae59af@mail.altenpts.nl> In-Reply-To: <20100423074150.24ae59af@mail.altenpts.nl> Subject: RE: Question about solaris CANNOT_STEP_HW_WATCHPOINTS macro Date: Fri, 23 Apr 2010 12:42:00 -0000 Message-ID: <002301cae2e2$34a4c3e0$9dee4ba0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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/msg00097.txt.bz2 I reproduced Pieter's results and filed a bug report: http://sourceware.org/bugzilla/show_bug.cgi?id=3D11531 This changes the scenery completely: it becomes important that CANNOT_STEP_HW_WATCHPOINTS macro does not get set. If, as Pedro said, GDB does not check for a hardware watchpoint=20 trigger after the step anyway, the whole code of this macro becomes useless and only creates problems. I will try to submit a testcase for this bug report. Pierre Muller > -----Message d'origine----- > De=A0: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la > part de Pieter Maljaars > Envoy=E9=A0: Friday, April 23, 2010 9:42 AM > =C0=A0: Joel Brobecker; Pierre Muller > Cc=A0: Peter.Schauer@regent.e-technik.tu-muenchen.de; gdb@sourceware.org; > 'Joseph S. Myers'; 'Pedro Alves' > Objet=A0: Re: Question about solaris CANNOT_STEP_HW_WATCHPOINTS macro >=20 > > 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 =3D 5; > > (gdb) print myrec.x > > $1 =3D 0 > > (gdb) watch myrec.x > > Hardware watchpoint 2: myrec.x > > (gdb) s > > 14 myrec.y =3D 3.4; >=20 > 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. >=20 > (gdb) start > Temporary breakpoint 1 at 0x8050681: file watchp.c, line 13. > Starting program: [...]/watchp >=20 > Temporary breakpoint 1, main () at watchp.c:13 > 13 myrec.x =3D 5; > (gdb) print myrec.x > $1 =3D 0 > (gdb) watch myrec.x > Hardware watchpoint 2: myrec.x > (gdb) s > Hardware watchpoint 2: myrec.x >=20 > Old value =3D 0 > New value =3D 5 > main () at watchp.c:14 > 14 myrec.y =3D 3.4; >=20 >=20 > 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. >=20 > Pieter Maljaars