Re: Fw: [ppc-linux-nat]: set access flag for h/w watchpoint even if it is only read or write (fwd)

[Daniel Jacobowitz <drow at false dot org>]

On Tue, Jul 11, 2006 at 11:09:10AM -0400, Wu Zhou wrote:
> >I think the cleanest solution is for breakpoint.c to get the idea of
> >the kind of support it can get from the target.  If the target
> >implements real read watchpoints, it should propagate that knowledge
> >to breakpoint.c, where it examines the watchpoints and decides which
> >one to announce.
> 
> Yes. That is a good idea. Maybe a target vector can be added for that  
> purpose. Every target can set that up when it initializes. What is  
> more, the underlying os need to tell what kind of watchpoint it  
> reports, maybe in the transfered-back siginfo struct. Then gdb can use  
> that information to know if it is a read hit or write hit.
> 
> Although it is the very clean, but there is one problem in this  
> method. The underlying os need to tell what the watchpoint hit is,  
> read or write. Current ppc/ppc64 kernel don't do that. it just report  
> the a hw watchpoint is hit and report the data address to gdb through  
> siginfo struct.

There's two issues here, I think.  They solve different problems.

First, there's the question of targets which can't set true "read"
watchpoints, but can set "access" watchpoints.  Right now the x86
simply accepts a request to insert a read watchpoint, and generates an
access watchpoint instead.  How about if we changed it to refuse to
insert read watchpoints, changed breakpoint.c to attempt an access
watchpoint if inserting a read watchpoint fails, and then store in the
breakpoint which type was inserted?

In b->loc is probably a good place.  Right now there's no information
there about which kind of watchpoint was inserted.  We could add a
new field, and store hw_read/hw_access/hw_write in it when we insert
the breakpoint.

Would that fix this problem?

Second, there's the question of which sort of watchpoint we've hit. If
the target could tell us, say, as a return value from
target_stopped_data_address, then we could only check read watchpoints
when a read watchpoint triggers.  But I think this is a smaller issue;
at worst we might report that both a write and read watchpoint had
triggered when really only a write watchpoint had.  And there's corner
cases, like instructions which both read and write an address; they
should trigger both read and write watchpoints but I doubt any platform
gives us enough information to figure out that that's happened.

-- 
Daniel Jacobowitz
CodeSourcery