From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15820 invoked by alias); 24 Dec 2002 00:57:14 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15813 invoked from network); 24 Dec 2002 00:57:14 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 24 Dec 2002 00:57:14 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gBO0UOB12381 for ; Mon, 23 Dec 2002 19:30:24 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gBO0v0n18409; Mon, 23 Dec 2002 19:57:01 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id gBO0v0n23118; Mon, 23 Dec 2002 16:57:00 -0800 Message-ID: <3E07B0DC.CC733B10@redhat.com> Date: Mon, 23 Dec 2002 16:59:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command References: <15875.24035.153991.390184@localhost.redhat.com> <3E07A1F2.E7B77C89@redhat.com> <20021224000211.GA8155@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00655.txt.bz2 Daniel Jacobowitz wrote: > > On Mon, Dec 23, 2002 at 03:53:22PM -0800, Michael Snyder wrote: > > Elena Zannoni wrote: > > > > > > This fixes the problem reported in: > > > http://sources.redhat.com/ml/gdb/2002-11/msg00144.html > > > > > > testsuite patch coming > > > > Elena, can you sum up in a sentence or two, what this change > > is intended to do? > > [Since I happen to be reading email right now, I'll do a sketchy > imitation.] > > The problem is that we were marking the breakpoint on the > user-specified line with the current frame. But when we hit that > breakpoint, if it's in a different function, it will have a different > frame. Right now we see that the frames don't match and resume > executing. > > Oops. OK, thanks. But we _need_ to mark the breakpoint with the current frame, because if the breakpoint is in the current frame, we don't want to stop in an inner recursive call, ie. not until the current frame hits the breakpoint. So this needs further consideration, and I don't think it can be approved as is. Michael > > > > > 2002-12-20 Elena Zannoni > > > > > > Fix PR breakpoints/898. > > > * breakpoint.c (until_break_command): Don't use selected_frame, > > > but the null frame. > > > > > > Index: breakpoint.c > > > =================================================================== > > > RCS file: /cvs/uberbaum/gdb/breakpoint.c,v > > > retrieving revision 1.104 > > > diff -u -p -r1.104 breakpoint.c > > > --- breakpoint.c 17 Dec 2002 17:27:44 -0000 1.104 > > > +++ breakpoint.c 20 Dec 2002 18:06:27 -0000 > > > @@ -5615,9 +5615,7 @@ until_break_command (char *arg, int from > > > > > > resolve_sal_pc (&sal); > > > > > > - breakpoint = > > > - set_momentary_breakpoint (sal,get_frame_id (deprecated_selected_frame), > > > - bp_until); > > > + breakpoint = set_momentary_breakpoint (sal, null_frame_id, bp_until); > > > > > > if (!event_loop_p || !target_can_async_p ()) > > > old_chain = make_cleanup_delete_breakpoint (breakpoint); > > > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer