From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20157 invoked by alias); 21 Jul 2009 03:19:24 -0000 Received: (qmail 20147 invoked by uid 22791); 21 Jul 2009 03:19:23 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_12,SARE_MSGID_LONG40,SPF_PASS,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from mail-pz0-f203.google.com (HELO mail-pz0-f203.google.com) (209.85.222.203) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Jul 2009 03:19:13 +0000 Received: by pzk41 with SMTP id 41so2082724pzk.12 for ; Mon, 20 Jul 2009 20:19:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.239.13 with SMTP id m13mr1092730wfh.220.1248146352111; Mon, 20 Jul 2009 20:19:12 -0700 (PDT) In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA07C00000@ecamlmw720.eamcs.ericsson.se> References: <6D19CA8D71C89C43A057926FE0D4ADAA07C00000@ecamlmw720.eamcs.ericsson.se> From: Hui Zhu Date: Tue, 21 Jul 2009 03:38:00 -0000 Message-ID: Subject: Re: [PRecord] Memory gets set even if users responds 'n' to query To: Marc Khouzam , Michael Snyder Cc: gdb-patches ml Content-Type: multipart/mixed; boundary=000e0cd14b1af200b3046f2eb73e 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-07/txt/msg00504.txt.bz2 --000e0cd14b1af200b3046f2eb73e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 3015 On Tue, Jul 21, 2009 at 10:15, Marc Khouzam wrot= e: > Hi, > > while looking into the query stuff we have been discussing I ran into > the weird behavior where PRecord sets memory even if I answer 'n' to the > query. =A0I've done a little troubleshooting and it seems that the query > code is not the problem. =A0So, I thought that maybe even though PRecord > returns > from its method right away when I say 'n' to the query, the memory > has already been changed. =A0Could that be? =A0I didn't investigate furth= er. > > Also, I didn't try it with changing registers. > > I'm pretty sure it used to work properly. > > Thanks > > Marc > > Here is the session: > > GNU gdb (GDB) 6.8.50.20090720-cvs > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. =A0Type "show > copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu". > For bug reporting instructions, please see: > ... > (gdb) l > 1 =A0 =A0 =A0 int main() { > 2 =A0 =A0 =A0 =A0 =A0 int a =3D 1; > 3 =A0 =A0 =A0 =A0 =A0 int b =3D 10; > 4 > 5 =A0 =A0 =A0 =A0 =A0 a++; > 6 =A0 =A0 =A0 =A0 =A0 b++; > 7 > 8 =A0 =A0 =A0 =A0 =A0 return a; > 9 =A0 =A0 =A0 } > 10 > (gdb) start > Temporary breakpoint 1 at 0x80483f5: file b.cc, line 2. > Starting program: /home/marc/testing/a.out > re > Temporary breakpoint 1, main () at b.cc:2 > 2 =A0 =A0 =A0 =A0 =A0 int a =3D 1; > (gdb) record > (gdb) n > 3 =A0 =A0 =A0 =A0 =A0 int b =3D 10; > (gdb) n > 5 =A0 =A0 =A0 =A0 =A0 a++; > (gdb) n > 6 =A0 =A0 =A0 =A0 =A0 b++; > (gdb) n > 8 =A0 =A0 =A0 =A0 =A0 return a; > (gdb) rn > 6 =A0 =A0 =A0 =A0 =A0 b++; > (gdb) p a > $1 =3D 2 > (gdb) set var a =3D 8 > Because GDB is in replay mode, writing to memory will make the execution > log unusable from this point onward. =A0Write memory at address > 0xbffff6b0?(y or [n]) n > (gdb) p a > $2 =3D 8 > (gdb) > > Thanks Marc. This issue is because when user answer n, function record_xfer_partial return -1 will not really cancel the memory change operation. I make a patch to change it to error. And I have check the code about register, it works OK. Because it already use error. Please help me review it. Thanks, Hui 2009-07-21 Hui Zhu * record.c (record_xfer_partial): Call error When nquery return "n". --- record.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/record.c +++ b/record.c @@ -997,7 +997,7 @@ record_xfer_partial (struct target_ops * "will make the execution log unusable from this " "point onward. Write memory at address %s?"), paddress (target_gdbarch, offset))) - return -1; + error (_("Process record canceled the operation.")); /* Destroy the record from here forward. */ record_list_release_next (); --000e0cd14b1af200b3046f2eb73e Content-Type: text/plain; charset=US-ASCII; name="reverse-fix-change-memory.txt" Content-Disposition: attachment; filename="reverse-fix-change-memory.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fxe27c3a0 Content-length: 667 LS0tCiByZWNvcmQuYyB8ICAgIDIgKy0KIDEgZmlsZSBjaGFuZ2VkLCAxIGlu c2VydGlvbigrKSwgMSBkZWxldGlvbigtKQoKLS0tIGEvcmVjb3JkLmMKKysr IGIvcmVjb3JkLmMKQEAgLTk5Nyw3ICs5OTcsNyBAQCByZWNvcmRfeGZlcl9w YXJ0aWFsIChzdHJ1Y3QgdGFyZ2V0X29wcyAqCiAJCSAgICAgICAgICJ3aWxs IG1ha2UgdGhlIGV4ZWN1dGlvbiBsb2cgdW51c2FibGUgZnJvbSB0aGlzICIK IAkJICAgICAgICAgInBvaW50IG9ud2FyZC4gIFdyaXRlIG1lbW9yeSBhdCBh ZGRyZXNzICVzPyIpLAogCQkgICAgICAgcGFkZHJlc3MgKHRhcmdldF9nZGJh cmNoLCBvZmZzZXQpKSkKLQkgICAgcmV0dXJuIC0xOworCSAgICBlcnJvciAo XygiUHJvY2VzcyByZWNvcmQgY2FuY2VsZWQgdGhlIG9wZXJhdGlvbi4iKSk7 CiAKIAkgIC8qIERlc3Ryb3kgdGhlIHJlY29yZCBmcm9tIGhlcmUgZm9yd2Fy ZC4gICovCiAJICByZWNvcmRfbGlzdF9yZWxlYXNlX25leHQgKCk7Cg== --000e0cd14b1af200b3046f2eb73e--