For those who didn't read the whole thread, the test-case:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/watchpoint.c?cvsroot=systemtap
On 12/10, Oleg Nesterov wrote:
>
> On 12/10, Oleg Nesterov wrote:
> >
> > On 12/09, CAI Qian wrote:
> > >
> > > ----- "Oleg Nesterov" <o...@redhat.com> wrote:
> > >
> > > > Thanks, but it doesn't fail for me on this machine...
> > >
> > > Hmm, it failed for me.
> > >
> > > # cd /root/ptrace-tests
> > >
> > > # make check
> > > ...
> > > FAIL: watchpoint
> >
> > OMG. Yet another test-case fails on powerpc ???? I didn't see this
> > failure in the previous reports or missed it ...
> >
> > I bet it fails without utrace too? (please don't tell it doesn't ;)
> >
> > Did you see it fails on other ppc64 machines?
> >
> >
> > Oh well. I spent this day grepping arch/powerpc to understand how
> > PTRACE_SET_DEBUGREG works and what is the problem. But I am afraid
> > this time I need a help from someone who understands the hardware
> > magic on powerpc.
> >
> > So far:
> >
> > - the test-case looks correct to me
>
> OOPS.
>
> I am not sure, will re-check tomorrow. But it seems to me gcc
> optimizes out "check = 1", despite the fact it is declared as
> volatile.
No, I misread the asm (which I don't understand anyway). The tracee
does write to check, and this is even seen by PTRACE_PEEKDATA.
Looks like a hardware problem to me. For example, this patch
--- watchpoint.c~ 2009-12-11 15:32:14.000000000 +0100
+++ watchpoint.c 2009-12-11 15:36:17.000000000 +0100
@@ -144,7 +144,7 @@ handler_fail (int signo)
raise (signo);
}
-static volatile long long check;
+volatile long long check;
int
main (void)
"fixes" the problem. This one
--- watchpoint.c~ 2009-12-11 15:32:14.000000000 +0100
+++ watchpoint.c 2009-12-11 15:38:10.000000000 +0100
@@ -169,7 +169,7 @@ main (void)
i = raise (SIGUSR1);
assert (i == 0);
- check = 1;
+ check = 0xfff;
i = raise (SIGUSR2);
assert (i == 0);
helps too (any value which can't be "immediate" for powerpc works,
unless I misinterpret asm again).
I give up, this needs a help from powerpc experts. As a last resort
I tried google,
# grep cpu /proc/cpuinfo
cpu : PPC970FX, altivec supported
cpu : PPC970FX, altivec supported
http://www.google.com/linux?q=powerpc+970FX+dabr+bug
from http://lists.ozlabs.org/pipermail/linuxppc-dev/2008-March/052910.html
Which is "IBM PowerPC 970FX RISC Microprocessor Errata List for DD3.X"
and contains "Erratum #8: DABRX register might not always be updated
correctly":
Projected Impact
The data address breakpoint function might not always
work.
Workaround
None.
Status
A fix is not planned at this time for the PowerPC 970FX.
but this machine sets set_dabr = pseries_set_dabr(), not pseries_set_xdabr(),
not sure this is relevant.
Gurus, please help!
Oleg.
