From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29660 invoked by alias); 17 Apr 2009 13:43:28 -0000 Received: (qmail 29647 invoked by uid 22791); 17 Apr 2009 13:43:24 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44,KAM_ADVERT2,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Apr 2009 13:43:16 +0000 Received: (qmail 21713 invoked from network); 17 Apr 2009 13:43:15 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Apr 2009 13:43:15 -0000 From: Pedro Alves To: David Daney Subject: Re: [Patch 2/2] MIPS hardware watchpoint support. Date: Fri, 17 Apr 2009 13:43:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <49D9AECB.7040302@gmail.com> <200904111817.36236.pedro@codesourcery.com> <49E765F7.1030201@caviumnetworks.com> In-Reply-To: <49E765F7.1030201@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904171443.26794.pedro@codesourcery.com> X-IsSubscribed: yes 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: 2009-04/txt/msg00430.txt.bz2 Thanks for the update. On Thursday 16 April 2009 18:08:07, David Daney wrote: > >> + =A0 =A0printf_unfiltered (" (addr=3D%lx, len=3D%d, type=3D%s)", > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* This code is for mips,= so casting CORE_ADDR > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to unsigned long sho= uld be okay. =A0*/ > >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(unsigned long)addr, len, > >=20 > > Why bother to explain that instead of using `paddr'? =A0If there's > > a reason, then it would be nice if it was spelled out in the > > comment. >=20 > Comment deleted, and types casted to (unsigned long long). Sorry to insist on a debug printf..., but that doesn't explain anything. This even looks more misterious. If this is an address, why the cast instead of paddr? -- you use paddr just a bit below. Is this because addr isn't really an address? > >=20 > >> -PASS: gdb.mi/mi-watch.exp: hw: watchpoint trigger > >> +FAIL: gdb.mi/mi-watch.exp: hw: watchpoint trigger (unknown output aft= er=20 > >> running) > >> > >> Reported instruction location of the watchpoint trigger is one=20 > >> instruction later and one line later. > >=20 > > Why is that? >=20 > I was mistaken, it is earlier, not later. With hardware watch points,=20 > $pc points to the faulting instruction, with software watch points $pc=20 > points to the following instruction. In a couple of tests, this results= =20 > in the reported line number being different than the expected value. I'm missing something and am still confused. PC points at the faulting instruction when the target reports the watchpoint hit to infrun --- . That step-over-watchpoint dance that patch 1/2 took care of c= omes into play. That should move the inferior to the following instruction, eva= luate the watchpoint expression, notice the value changed, and report to the user. Why does the PC still point at the faulting instruction? --=20 Pedro Alves