This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: A problem about read / access watchpoint
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