Re: [Patch 2/2] MIPS hardware watchpoint support.

[Pedro Alves <pedro at codesourcery dot com>]

Thanks for the update.

On Thursday 16 April 2009 18:08:07, David Daney wrote:
> >> + ? ?printf_unfiltered (" (addr=%lx, len=%d, type=%s)",
> >> + ? ? ? ? ? ? ? ? ? ? ?/* This code is for mips, so casting CORE_ADDR
> >> + ? ? ? ? ? ? ? ? ? ? ? ? to unsigned long should be okay. ?*/
> >> + ? ? ? ? ? ? ? ? ? ? ?(unsigned long)addr, len,
> > 
> > Why bother to explain that instead of using `paddr'? ?If there's
> > a reason, then it would be nice if it was spelled out in the
> > comment.
> 
> 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?

> > 
> >> -PASS: gdb.mi/mi-watch.exp: hw: watchpoint trigger
> >> +FAIL: gdb.mi/mi-watch.exp: hw: watchpoint trigger (unknown output after 
> >> running)
> >>
> >> Reported instruction location of the watchpoint trigger is one 
> >> instruction later and one line later.
> > 
> > Why is that?
> 
> I was mistaken, it is earlier, not later.  With hardware watch points, 
> $pc points to the faulting instruction, with software watch points $pc 
> points to the following instruction.  In a couple of tests, this results 
> 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 comes
into play.  That should move the inferior to the following instruction, evaluate
the watchpoint expression, notice the value changed, and report to the
user.  Why does the PC still point at the faulting instruction?

-- 
Pedro Alves