From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8896 invoked by alias); 3 Jan 2003 00:12:15 -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 8888 invoked from network); 3 Jan 2003 00:12:14 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 3 Jan 2003 00:12:14 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h02NikB18844 for ; Thu, 2 Jan 2003 18:44:46 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h030C2a08330; Thu, 2 Jan 2003 19:12:02 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h030C1m29751; Thu, 2 Jan 2003 19:12:01 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id 69C92FF78; Thu, 2 Jan 2003 19:16:23 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15892.54871.381942.260248@localhost.redhat.com> Date: Fri, 03 Jan 2003 00:12:00 -0000 To: msnyder@redhat.com Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command In-Reply-To: <15892.41806.882466.952438@localhost.redhat.com> References: <15875.24035.153991.390184@localhost.redhat.com> <3E07A1F2.E7B77C89@redhat.com> <20021224000211.GA8155@nevyn.them.org> <3E07B0DC.CC733B10@redhat.com> <20021224010306.GA10409@nevyn.them.org> <3E14A019.4A600913@redhat.com> <15892.41806.882466.952438@localhost.redhat.com> X-SW-Source: 2003-01/txt/msg00042.txt.bz2 Elena Zannoni writes: > > Nevertheless, that is and has always been the intent. > > If you're in factorial(5), and you say "until 100", > > you don't stop until line 100 is hit by factorial(5). > > > I am tracking down this to something that changed between (ahem...) > 4.18 and 5.0. The code in breakpoint.c didn't change. Right now, > stepping the two gdb's side to side, I can see a difference in > get_prev_frame, because of a different value returned by > FRAME_CHAIN_VALID. :-( (i have not still stepped past that to see how > that could influence the until foo behavior, maybe it doesn't). > > The behavior you specify above is in 5.0 and not in 4.18, while the > 'until foo' works in 4.18 and is broken in 5.0. > > More digging. > > Elena OK. The reason for which 'until foo' worked at all in 4.18 is totally fortuitous. It is because of this patch in breakpoint.c: 1998-09-08 Jason Molenda (jsm@bugshack.cygnus.com) * breakpoint.c (bpstat_stop_status): Declare a bp match if the current fp matches the bp->fp OR if the current fp is less than the bp->fp if we're looking at a bp_step_resume breakpoint. Index: breakpoint.c =================================================================== RCS file: /cvs/cvsfiles/src/gdb/breakpoint.c,v retrieving revision 1.190 retrieving revision 1.191 diff -u -p -p -r1.190 -r1.191 --- breakpoint.c 1998/07/17 15:29:10 1.190 +++ breakpoint.c 1998/09/09 04:16:57 1.191 @@ -1506,7 +1506,9 @@ bpstat_stop_status (pc, not_a_breakpoint else if (DECR_PC_AFTER_BREAK != 0 || must_shift_inst_regs) real_breakpoint = 1; - if (b->frame && b->frame != (get_current_frame ())->frame) + if (b->frame && b->frame != (get_current_frame ())->frame && + (b->type == bp_step_resume && + (get_current_frame ())->frame INNER_THAN b->frame)) bs->stop = 0; else { Note that this added condition is always false for a bp_until type breakpoint. So, effectively we were invalidating the check of the current frame vs. bp->frame. And we always stopped. However, since we were not checking the frames, the case Michael wants didn't work. The patch above was reverted in 1999: 1999-08-13 Jim Kingdon * breakpoint.c (bpstat_stop_status): Revert 1998-09-08 change to ->frame matching. The change did not match the ChangeLog entry, looked fishy, and caused infinite stepping when running "next" from main on sparc w/ RH Linux. Thanks to Jakub for the report. the effect was that the frame matching check was re-enabled, and so 'until foo' stopped working. I don't think there is a way to have both behaviors work correctly. I thought of checking that the pc which you want to run until is in the same function as the one of the selected frame, and in that case enforce the check (by using a non-null frame for the bp_until), otherwise use the null frame (which disables the check). But what would be the correct behavior if you say: "until bar" where bar is recursive, and you are in "bar" at the moment? This doesn't work currently. It seems intuitive that you would stop the next time you enter "bar". Right now you end up at the caller of "bar". I think it is a matter of deciding which behavior is more useful. (note that I tried to revert Jason's patch in stock 4.18 and 'until foo' stopped working, i.e. it wasn't something else that broke between 4.18 and 5.0) Elena