From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31975 invoked by alias); 9 Jun 2009 02:18:56 -0000 Received: (qmail 31966 invoked by uid 22791); 9 Jun 2009 02:18:55 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from wf-out-1314.google.com (HELO wf-out-1314.google.com) (209.85.200.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 09 Jun 2009 02:18:49 +0000 Received: by wf-out-1314.google.com with SMTP id 23so1178453wfg.24 for ; Mon, 08 Jun 2009 19:18:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.194.1 with SMTP id r1mr2475356wff.166.1244513927857; Mon, 08 Jun 2009 19:18:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 09 Jun 2009 02:18: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: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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-06/txt/msg00203.txt.bz2 PING On Mon, May 11, 2009 at 15:07, Hui Zhu wrote: > PING > > On Wed, May 6, 2009 at 15:23, Hui Zhu wrote: >> 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 =A0Hui Zhu =A0 >> >> =A0 =A0 =A0 * infrun.c (handle_inferior_event): Check frame_id when >> =A0 =A0 =A0 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_fra= me_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 m= ode. >>> >>> 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 ra= nge 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 8048= 424 <_Z9factoriali> >>> =A08048447: =A0 =A0 =A0 0f af 45 08 =A0 =A0 =A0 =A0 =A0 =A0 imul =A0 0x= 8(%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 =A0r= et >>> 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= to: >>> =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_rang= e_end. >>> >>> I don't find that it affect the reverse debug or something. =A0So I did= n't fix it. >>> >>> >>> >>> >>> Thanks, >>> Hui >>> >> >