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

[Wu Zhou <woodzltc at cn dot ibm dot com>]

> This doesn't happen on x86, with this test program:
>
>     #include <stdio.h>
>
>     int main (void)
>     {
>       int var1 = 0, var2;
>       var1 = 10;
>       var2 = var1;
>
>       printf ("%d %d\n", var1, var2);
>       return 0;
>     }
>
> I think the reason it works for me is that on x86, there's no real
> support for read watchpoints, so we actually set a read-write
> watchpoint, and then the logic of watchpoint_check does TRT.
>
> What is the situation with this on a PPC?  What kinds of data
> breakpoints does it support, and what associated functionality can we
> use in the ptrace call or its PPC equivalent?

Embedded powerpc processors have optional hardware support (specilized  
registers) for watchpoints. If these registers are available, they  
will support read and write watchpoints at the same time. The  
situation is the same with POWER processors.

To insert read or write watchpoint, three new ptrace commands are  
added for ppc/ppc64 kernel: SET_DEBUGREG, GET_DEBUGREG, GET_SIGINFO.  
SET_DEBUGREG is used for setting the value of watchpoint register.  
GET_DEBUGREG is for getting the value of watchpoint register.  
GET_SIGINFO is for getting the siginfo struct when a trap is captured,  
the watched data address is in this struct.

> > My solution is to let gdb update the value stored in the watched
> variable,
> > so that it always get the fresh value for comparison.

> That will work, but the question is: is this the optimal solution for
> the PPC?  Maybe there's a better solution, one that doesn't slow down
> the normal case.

Yes. This might slow down read watchpoint, mainly when there are more  
write operation than read operation. But for write watchpoint, we can  
eliminate that slowdown by only setting write flag.

> > Another solution might be to change the verify logic of read watchpoint
> > hit in watchpoint_check.  Maybe we can just trust the underlying os will
> > only trigger in read hit?
>
> The question is, how to do that without breaking other platforms, like
> x86, which we cannot trust.  If you can come up with a design that
> accommodates both types of situations, I will be happy to review it.

I am not that familar with the situation in x86 platform. But I am  
willing to take some look into that to see if I can come out with any  
solution.

> Daniel, could you please point me to Ulrich's change, either in
> ChangeLogs or in the sources?  I cannot find it forf some reason.
>
> > Comparing all these solution, my solution is the most simple one.  I
> mean,
> > it makes little change to the current code.  To address the slowdown, we
> > can still use the original flags for write hit.
> >
> > What is your idea on this?
>
> 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.

So what about commit my code first, although there are some slowdown.  
And then we can follow the above method to resolve the problem in both  
kernel and gdb side?

> Please note that there are complications in this area: a user could
> have legitimately set several different watchpoints on the same
> address, each one with its own type (read, write, access) and its own
> set of conditions and/or commands.  Whatever new design we come up
> with, it has to support these complicated situations, because the user
> will expect GDB to announce only those watchpoints which meet the
> conditions and type constraints.  For example, what happens with your
> solution if I put both read and write watchpoints on the same
> variable?  The current code does TRT on x86 in that case.  As you see
> below, it correctly announces each one of the two watchpoints where
> expected (except for a slight off-by-one shift in line numbers):

My current code can handle this situation.

Regards
- Wu Zhou