From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13566 invoked by alias); 16 Jan 2006 09:59:54 -0000 Received: (qmail 13539 invoked by uid 22791); 16 Jan 2006 09:59:53 -0000 X-Spam-Check-By: sourceware.org Received: from ausmtp03.au.ibm.com (HELO ausmtp03.au.ibm.com) (202.81.18.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 16 Jan 2006 09:59:51 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp03.au.ibm.com (8.12.10/8.12.10) with ESMTP id k0GA30lH085306 for ; Mon, 16 Jan 2006 21:03:01 +1100 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.250.244]) by sd0208e0.au.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0GA2re4280830 for ; Mon, 16 Jan 2006 21:02:53 +1100 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.12.11/8.13.3) with ESMTP id k0G9xjnU010597 for ; Mon, 16 Jan 2006 20:59:46 +1100 Received: from wks190239wss.cn.ibm.com (wks190239wss.cn.ibm.com [9.181.133.187] (may be forged)) by d23av03.au.ibm.com (8.12.11/8.12.11) with ESMTP id k0G9xcWP010512; Mon, 16 Jan 2006 20:59:41 +1100 Date: Mon, 16 Jan 2006 09:59:00 -0000 From: Wu Zhou To: Jim Blandy cc: gdb@sources.redhat.com, anton@au1.ibm.com, pgilliam@us.ibm.com Subject: Re: A problem about read / access watchpoint In-Reply-To: <8f2776cb0601152317x5146926ard81b8ad36ba2d362@mail.gmail.com> Message-ID: References: <8f2776cb0601152317x5146926ard81b8ad36ba2d362@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00136.txt.bz2 On Sun, 15 Jan 2006, Jim Blandy wrote: > On 1/15/06, Wu Zhou 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 : stwu r1,-32(r1) 0x10000458 : mflr r0 0x1000045c : stw r31,28(r1) 0x10000460 : stw r0,36(r1) 0x10000464 : mr r31,r1 0x10000468 : stw r3,8(r31) 0x1000046c : stw r4,12(r31) 0x10000470 : li r0,0 0x10000474 : stw r0,16(r31) 0x10000478 : addi r0,r31,16 0x1000047c : mr r3,r0 0x10000480 : bl 0x10000418 0x10000484 : lis r9,4097 0x10000488 : lwz r0,16(r31) 0x1000048c : stw r0,2452(r9) 0x10000490 : lis r11,4097 0x10000494 : lis r9,4096 0x10000498 : addi r3,r9,2160 0x1000049c : lwz r4,2452(r11) 0x100004a0 : lwz r5,16(r31) 0x100004a4 : crclr 4*cr1+eq 0x100004a8 : bl 0x100109e8 0x100004ac : mr r3,r0 0x100004b0 : lwz r11,0(r1) 0x100004b4 : lwz r0,4(r11) 0x100004b8 : mtlr r0 0x100004bc : lwz r31,-4(r11) 0x100004c0 : mr r1,r11 0x100004c4 : 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