Re: A problem about read / access watchpoint

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

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