A problem about read / access watchpoint

A problem about read / access watchpoint

[Wu Zhou]

In the process of writing a testcase for read / access watchpoint, I find 
something very strange: read/access watchpoints don't always work as 
expected.  Here is a simplified example:

1 #include <stdio.h>
2
3 int var0 = 0;
4 
5 void subr (int *var1)
6 {
7   printf ("just to do sth\n");
8 }
9
10 void main (int argc, char **argv)
11 {
12  int var1 = 0;
13
14  subr (&var1);
15  var0 = var1;
16  printf ("var0 = %d, var1 = %d\n", var0, var1);
17 }

if I set read watchpoint on var1, it will only catch the watchpoint at the 
line 16 (for both x86 and ppc64).  In my opinion, it should stop at line 
15 as well.

if I set access watchpoint on var1, it will stop at line 12, 15, 16 on 
ppc64, and only stop line 12, 16 on x86. 

I did some tracing on that, and find that the kernel _did_ issue signal 
trap on line 15, and gdb could also get the stopped data address by 
ptrace. But when gdb call watchpoint_check to check if the value changed 
or not. It will reports WP_VALUE_CHANGED, which really confuse me.

I am now reading the code of watchpoint_check, but I don't understand why 
it will compare the new_val with b->val, and not bs->old_value.  The code 
following the comparison is also out of my understanding:

      struct value *mark = value_mark ();
      struct value *new_val = evaluate_expression (bs->breakpoint_at->exp);
      if (!value_equal (b->val, new_val))
	{
	  release_value (new_val);
	  value_free_to_mark (mark);
	  bs->old_val = b->val;
	  b->val = new_val;
	  /* We will stop here */
	  return WP_VALUE_CHANGED;
	}

Anyone can help me out of this question?  Thanks a lot.

Regards
- Wu Zhou

Re: A problem about read / access watchpoint

[Jim Blandy]

On 1/15/06, Wu Zhou <woodzltc@cn.ibm.com> wrote:
> I did some tracing on that, and find that the kernel _did_ issue signal
> trap on line 15, and gdb could also get the stopped data address by
> ptrace. But when gdb call watchpoint_check to check if the value changed
> or not. It will reports WP_VALUE_CHANGED, which really confuse me.

Just out of curiosity, could you post a disassembly of main?  The
kernel is watching what the machine code version of the program does,
and I wouldn't assume that it was the same as what the source code
version does, even if you compile with -O0.

Re: A problem about read / access watchpoint

[Wu Zhou]

On Sun, 15 Jan 2006, Jim Blandy wrote:

> On 1/15/06, Wu Zhou <woodzltc@cn.ibm.com> wrote:
> > I did some tracing on that, and find that the kernel _did_ issue signal
> > trap on line 15, and gdb could also get the stopped data address by
> > ptrace. But when gdb call watchpoint_check to check if the value changed
> > or not. It will reports WP_VALUE_CHANGED, which really confuse me.
> 
> Just out of curiosity, could you post a disassembly of main?  The
> kernel is watching what the machine code version of the program does,
> and I wouldn't assume that it was the same as what the source code
> version does, even if you compile with -O0.

Hi Jim,

Here is a snapshot of the debugging session (on ppc64), the disassembly 
of main is included:

[woodzltc@plinuxt2 gdb-cvs-6.4]$ ./build64/gdb/gdb -q ./rwatch
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) b main
Breakpoint 1 at 0x10000470: file rwatch.c, line 13.
(gdb) r
Starting program: /home/woodzltc/DE-GDB/gdb-cvs-6.4/rwatch
Failed to read a valid object file image from memory.

Breakpoint 1, main (argc=1, argv=0xffa22ab4) at rwatch.c:13
13        int var1 = 0;
(gdb) rwatch var1
Hardware read watchpoint 2: var1
(gdb) disassemble main
Dump of assembler code for function main:
0x10000454 <main+0>:    stwu    r1,-32(r1)
0x10000458 <main+4>:    mflr    r0
0x1000045c <main+8>:    stw     r31,28(r1)
0x10000460 <main+12>:   stw     r0,36(r1)
0x10000464 <main+16>:   mr      r31,r1
0x10000468 <main+20>:   stw     r3,8(r31)
0x1000046c <main+24>:   stw     r4,12(r31)
0x10000470 <main+28>:   li      r0,0
0x10000474 <main+32>:   stw     r0,16(r31)
0x10000478 <main+36>:   addi    r0,r31,16
0x1000047c <main+40>:   mr      r3,r0
0x10000480 <main+44>:   bl      0x10000418 <subr>
0x10000484 <main+48>:   lis     r9,4097
0x10000488 <main+52>:   lwz     r0,16(r31)
0x1000048c <main+56>:   stw     r0,2452(r9)
0x10000490 <main+60>:   lis     r11,4097
0x10000494 <main+64>:   lis     r9,4096
0x10000498 <main+68>:   addi    r3,r9,2160
0x1000049c <main+72>:   lwz     r4,2452(r11)
0x100004a0 <main+76>:   lwz     r5,16(r31)
0x100004a4 <main+80>:   crclr   4*cr1+eq
0x100004a8 <main+84>:   bl      0x100109e8 <printf@plt>
0x100004ac <main+88>:   mr      r3,r0
0x100004b0 <main+92>:   lwz     r11,0(r1)
0x100004b4 <main+96>:   lwz     r0,4(r11)
0x100004b8 <main+100>:  mtlr    r0
0x100004bc <main+104>:  lwz     r31,-4(r11)
0x100004c0 <main+108>:  mr      r1,r11
0x100004c4 <main+112>:  blr
End of assembler dump.
(gdb) c
Continuing.
just to do sth
Hardware read watchpoint 2: var1

Value = 0
0x100004a4 in main (argc=1, argv=0xffa22ab4) at rwatch.c:17
17        printf ("var0 = %d, var1 = %d\n", var0, var1);
(gdb) p &var1
$1 = (int *) 0xffa22860


Kernel messages show that var1 is hit two times:

[root@plinuxt2 SPECS]# dmesg -c
ptrace_getsiginfo: data.si_addr is 0x10000474
ptrace_getsiginfo: data.si_addr is 0xffa22860  ===> The first time var1 is hit
ptrace_getsiginfo: data.si_addr is 0x1000048c
ptrace_getsiginfo: data.si_addr is 0xffa22860  ===> The second time var1 is hit
ptrace_getsiginfo: data.si_addr is 0x100004a4  
   ===> When a watchpoint/breakpoint is hit, it need to single step to 
        execute that instruction, so this is the insturction address to 
        access var1  


The GDB is patched with my patch to add h/w watchpoint to ppc64. The 
kernel is 2.6.15-git8.  I only added a few printk to print the faulting 
address.


Regards
- Wu Zhou

Re: A problem about read / access watchpoint

[Wu Zhou]

On Sun, 15 Jan 2006, Jim Blandy wrote:

> On 1/15/06, Wu Zhou <woodzltc@cn.ibm.com> wrote:
> > I did some tracing on that, and find that the kernel _did_ issue signal
> > trap on line 15, and gdb could also get the stopped data address by
> > ptrace. But when gdb call watchpoint_check to check if the value changed
> > or not. It will reports WP_VALUE_CHANGED, which really confuse me.
> 
> Just out of curiosity, could you post a disassembly of main?  The
> kernel is watching what the machine code version of the program does,
> and I wouldn't assume that it was the same as what the source code
> version does, even if you compile with -O0.
> 

This is the related debugging session on x86:

(gdb) p &var1
$1 = (int *) 0xbff312c4
(gdb) rwatch var1
Hardware read watchpoint 2: var1
(gdb) c
Continuing.
just to do sth
Hardware read watchpoint 2: var1

Value = 0
0x080483c0 in main (argc=1, argv=0xbff31354) at rwatch.c:17
17        printf ("var0 = %d, var1 = %d\n", var0, var1);
(gdb) disassemble main
Dump of assembler code for function main:
0x08048380 <main+0>:    push   %ebp
0x08048381 <main+1>:    mov    %esp,%ebp
0x08048383 <main+3>:    sub    $0x8,%esp
0x08048386 <main+6>:    and    $0xfffffff0,%esp
0x08048389 <main+9>:    mov    $0x0,%eax
0x0804838e <main+14>:   add    $0xf,%eax
0x08048391 <main+17>:   add    $0xf,%eax
0x08048394 <main+20>:   shr    $0x4,%eax
0x08048397 <main+23>:   shl    $0x4,%eax
0x0804839a <main+26>:   sub    %eax,%esp
0x0804839c <main+28>:   movl   $0x0,0xfffffffc(%ebp)
0x080483a3 <main+35>:   sub    $0xc,%esp
0x080483a6 <main+38>:   lea    0xfffffffc(%ebp),%eax
0x080483a9 <main+41>:   push   %eax
0x080483aa <main+42>:   call   0x8048368 <subr>
0x080483af <main+47>:   add    $0x10,%esp
0x080483b2 <main+50>:   mov    0xfffffffc(%ebp),%eax   ===> read var1?
0x080483b5 <main+53>:   mov    %eax,0x80495e8
0x080483ba <main+58>:   sub    $0x4,%esp
0x080483bd <main+61>:   pushl  0xfffffffc(%ebp)        ===> read var1?
0x080483c0 <main+64>:   pushl  0x80495e8
0x080483c6 <main+70>:   push   $0x80484c8
0x080483cb <main+75>:   call   0x80482b0 <printf@plt>
0x080483d0 <main+80>:   add    $0x10,%esp
0x080483d3 <main+83>:   leave
0x080483d4 <main+84>:   ret
End of assembler dump.
(gdb) bt
#0  0x080483c0 in main (argc=1, argv=0xbff31354) at rwatch.c:17
(gdb) info registers
eax            0x0      0
ecx            0x0      0
edx            0xf      15
ebx            0xaa7ff4 11173876
esp            0xbff312a8       0xbff312a8
ebp            0xbff312c8       0xbff312c8         (== &var - 4)
esi            0xbff31354       -1074588844
edi            0xbff312e0       -1074588960
eip            0x80483c0        0x80483c0 <main+64>
eflags         0x296    662
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51 


I am not that comfortable with x86 assembly. But it seems that I am 
correct on the guess, right?

Regards
- Wu Zhou