From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14593 invoked by alias); 6 May 2009 07:24:35 -0000 Received: (qmail 14561 invoked by uid 22791); 6 May 2009 07:24:30 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.189) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 May 2009 07:23:53 +0000 Received: by ti-out-0910.google.com with SMTP id a1so533650tib.12 for ; Wed, 06 May 2009 00:23:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.110.69.5 with SMTP id r5mr63865tia.22.1241594630627; Wed, 06 May 2009 00:23:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 06 May 2009 07:24:00 -0000 Message-ID: Subject: Re: [RFA] Patch to fix reverse-debug recursion function tail bug From: Hui Zhu To: Michael Snyder Cc: Marc Khouzam , "gdb-patches@sourceware.org" Content-Type: multipart/mixed; boundary=0016e652de56e9e255046939468c 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-05/txt/msg00104.txt.bz2 --0016e652de56e9e255046939468c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 3499 Hi Michael, Like the prev patch I send to you, this issue still affect cvs-head and the patch can fix it. Please help me review it. The attachment is the new patch follow cvs-head. 2009-05-06 Hui Zhu * infrun.c (handle_inferior_event): Check frame_id when check range in reverse debug mode. Thanks, Hui On Sat, Mar 21, 2009 at 16:52, Hui Zhu wrote: > Hi, > > This patch is for bug report by Marc in > http://sourceware.org/ml/gdb/2009-03/msg00127.html. > > This bug in "handle_inferior_event" deal with recursion function tail > in reverse debug. > infrun: infwait_normal_state > infrun: TARGET_WAITKIND_STOPPED > infrun: stop_pc =3D 0x8048457 > infrun: stepping inside range [0x8048457-0x804845a] > infrun: stop_stepping > factorial (x=3D4) at b.cc:5 > > Inferior already step into another frame. But because this is a > recursion function call, And 0x8048457 is in > ecs->event_thread->step_range_start and > ecs->event_thread->step_range_start. > > So gdb run in: > > if (stop_pc >=3D ecs->event_thread->step_range_start > =A0 =A0 =A0&& stop_pc < ecs->event_thread->step_range_end) > =A0 =A0{ > > This code is in front of: > =A0if (!frame_id_eq (get_frame_id (get_current_frame ()), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ecs->event_thread->step_frame_id) > =A0 =A0 =A0&& (frame_id_eq (frame_unwind_id (get_current_frame ()), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ecs->event_thread->step_frame= _id) > =A0 =A0 =A0 =A0 =A0|| execution_direction =3D=3D EXEC_REVERSE)) > > So gdb check range without check frame_id. > > So I make a patch to check frame_id when check range in reverse debug mod= e. > > 2008-03-21 =A0Hui Zhu =A0 > > =A0 =A0 =A0 =A0* infrun.c (handle_inferior_event): Check frame_id when > =A0 =A0 =A0 =A0check range in reverse debug mode. > > > > > > Actually, there is another thing, when gdb begin reverse-debug, it's rang= e is: > =A08048439: =A0 =A0 =A0 8b 45 08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mov =A0 = =A00x8(%ebp),%eax > =A0804843c: =A0 =A0 =A0 83 e8 01 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sub =A0 = =A0$0x1,%eax > =A0804843f: =A0 =A0 =A0 89 04 24 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mov =A0 = =A0%eax,(%esp) > =A08048442: =A0 =A0 =A0 e8 dd ff ff ff =A0 =A0 =A0 =A0 =A0call =A0 804842= 4 <_Z9factoriali> > =A08048447: =A0 =A0 =A0 0f af 45 08 =A0 =A0 =A0 =A0 =A0 =A0 imul =A0 0x8(= %ebp),%eax > =A0804844b: =A0 =A0 =A0 89 45 fc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mov =A0 = =A0%eax,-0x4(%ebp) > Why is changed to infrun: stepping inside range [0x8048457-0x804845a]? > That is because when inferior step at: > =A08048458: =A0 =A0 =A0 c3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret > In this address, $ebp is same with high level function and this > function is factorial too. > So the gdb can't found inferior step into another frame. =A0It will run t= o: > =A0ecs->event_thread->step_range_start =3D stop_pc_sal.pc; > =A0ecs->event_thread->step_range_end =3D stop_pc_sal.end; > =A0ecs->event_thread->step_frame_id =3D get_frame_id (get_current_frame (= )); > =A0ecs->event_thread->current_line =3D stop_pc_sal.line; > =A0ecs->event_thread->current_symtab =3D stop_pc_sal.symtab; > > =A0if (debug_infrun) > =A0 =A0 fprintf_unfiltered (gdb_stdlog, "infrun: keep going\n"); > =A0keep_going (ecs); > } > So ecs->event_thread->step_range_start and ecs->event_thread->step_range_= end. > > I don't find that it affect the reverse debug or something. =A0So I didn'= t fix it. > > > > > Thanks, > Hui > --0016e652de56e9e255046939468c Content-Type: text/plain; charset=US-ASCII; name="fix-function-tail-stack-same.txt" Content-Disposition: attachment; filename="fix-function-tail-stack-same.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fudpdbl40 Content-length: 944 LS0tCiBpbmZydW4uYyB8ICAgIDUgKysrKy0KIDEgZmlsZSBjaGFuZ2VkLCA0 IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkKCi0tLSBhL2luZnJ1bi5j CisrKyBiL2luZnJ1bi5jCkBAIC0zNDIxLDcgKzM0MjEsMTAgQEAgaW5mcnVu OiBCUFNUQVRfV0hBVF9TRVRfTE9OR0pNUF9SRVNVTUUgKAogICAgICBiZXlv bmQgdGhlIHN0ZXAgcmFuZ2UsIGFuZCBOT1QgdGhlIGFkZHJlc3Mgb2YgdGhl IGxhc3QgaW5zdHJ1Y3Rpb24KICAgICAgd2l0aGluIGl0ISAqLwogICBpZiAo c3RvcF9wYyA+PSBlY3MtPmV2ZW50X3RocmVhZC0+c3RlcF9yYW5nZV9zdGFy dAotICAgICAgJiYgc3RvcF9wYyA8IGVjcy0+ZXZlbnRfdGhyZWFkLT5zdGVw X3JhbmdlX2VuZCkKKyAgICAgICYmIHN0b3BfcGMgPCBlY3MtPmV2ZW50X3Ro cmVhZC0+c3RlcF9yYW5nZV9lbmQKKyAgICAgICYmIChmcmFtZV9pZF9lcSAo Z2V0X2ZyYW1lX2lkIChnZXRfY3VycmVudF9mcmFtZSAoKSksCisJCSAgICAg IGVjcy0+ZXZlbnRfdGhyZWFkLT5zdGVwX2ZyYW1lX2lkKQorICAgICAgICAg IHx8IGV4ZWN1dGlvbl9kaXJlY3Rpb24gIT0gRVhFQ19SRVZFUlNFKSkKICAg ICB7CiAgICAgICBpZiAoZGVidWdfaW5mcnVuKQogCWZwcmludGZfdW5maWx0 ZXJlZCAoZ2RiX3N0ZGxvZywgImluZnJ1bjogc3RlcHBpbmcgaW5zaWRlIHJh bmdlIFsweCVzLTB4JXNdXG4iLAo= --0016e652de56e9e255046939468c--