From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17963 invoked by alias); 14 Sep 2009 17:10:47 -0000 Received: (qmail 17947 invoked by uid 22791); 14 Sep 2009 17:10:45 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_12,SPF_PASS,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Sep 2009 17:10:42 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n8EHAXr4025968; Mon, 14 Sep 2009 12:10:37 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 12:10:20 -0500 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 12:10:20 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 14 Sep 2009 13:10:19 -0400 From: Marc Khouzam To: "'Hui Zhu'" , "'Daniel Jacobowitz'" , "'gdb@sourceware.org'" , "'Michael Snyder'" , "'gdb-patches ml'" Date: Mon, 14 Sep 2009 17:10:00 -0000 Subject: RE: PRecord sets memory even when it says it did not Message-ID: References: <20090914155327.GA26740@caradoc.them.org> In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00412.txt.bz2 =20 > -----Original Message----- > From: Hui Zhu [mailto:teawater@gmail.com]=20 > Sent: Monday, September 14, 2009 12:15 PM > To: Daniel Jacobowitz; Marc Khouzam; gdb@sourceware.org;=20 > Michael Snyder; gdb-patches ml > Subject: Re: PRecord sets memory even when it says it did not >=20 > On Mon, Sep 14, 2009 at 23:53, Daniel Jacobowitz=20 > wrote: > > On Mon, Sep 14, 2009 at 12:39:35PM +0800, Hui Zhu wrote: > >> > (gdb) set var a =3D 8 > >> > Because GDB is in replay mode, writing to memory will=20 > make the execution log unusable from this point onward. =A0 > Write memory at address 0xbffff6a0?(y or [n]) n > >> > Process record canceled the operation. > >> > (gdb) p a > >> > $2 =3D 8 > > > > This should refetch the value from the target. =A0What value=20 > is cached? >=20 > This value didn't really changed. It just be changed in cache, but > not memory. If you s or rs and check "a" again, you will found that > "a"'s value is right. I think Hui is right. I ran another test with printf and stopping precord and the memory seems ok, please see session below. > BTW, this is really a strange thing. If answer is enter, everything > is OK. If answer is no, it was changed. For me the problem happens both times, when pressing 'n' or . (you can see that in the session below too) (gdb) l 1 #include 2 int main() 3 { 4 int a =3D 0; 5 printf("a is %d\n",a); 6 return 0; 7 } (gdb) start Temporary breakpoint 1 at 0x8048485: file a.cc, line 4. Starting program: /local/lmckhou/testing/a.out=20 re Temporary breakpoint 1, main () at a.cc:4 4 int a =3D 0; (gdb) rec (gdb) n 5 printf("a is %d\n",a); (gdb) n a is 0 6 return 0; (gdb) rn 5 printf("a is %d\n",a); (gdb) p a $1 =3D 0 (gdb) set var a=3D8 Because GDB is in replay mode, writing to memory will make the execution lo= g unusable from this point onward. Write memory at address 0xbfffadf0?(y o= r [n])=20 Process record canceled the operation. (gdb) p a $2 =3D 8 (gdb) rec stop Delete recorded log and stop recording?(y or n) y (gdb) p a $3 =3D 8 (gdb) n a is 0 <------------------------------------------ a is actually set= correctly 6 return 0; (gdb) p a $4 =3D 0 >=20 >=20 > > > >> 2009-09-14 =A0Hui Zhu =A0 > >> > >> =A0 =A0 =A0 * record.c (record_xfer_partial): Call free_all_values when > >> =A0 =A0 =A0 cancel the operation. > > > > I don't think this is a good idea; this is a memory management > > function. =A0It's not supposed to change the apparent values. > > >=20 > Agree. Looks we have a strange thing need to be handled. >=20 >=20 > Thanks, > Hui >=20