On 12/11, Oleg Nesterov wrote:
>
> 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
or you can look at
https://www.redhat.com/archives/utrace-devel/2009-December/msg00096.html
it is very easy to reproduce the problem with gdb.
> 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.
