Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Elena Zannoni <ezannoni@redhat.com>
To: msnyder@redhat.com
Cc: Daniel Jacobowitz <drow@mvista.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA/PATCH] breakpoint.c: fix until command
Date: Fri, 03 Jan 2003 00:12:00 -0000	[thread overview]
Message-ID: <15892.54871.381942.260248@localhost.redhat.com> (raw)
In-Reply-To: <15892.41806.882466.952438@localhost.redhat.com>

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  <http://developer.redhat.com/>

        * 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


  parent reply	other threads:[~2003-01-03  0:12 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-20 10:19 Elena Zannoni
2002-12-23 15:55 ` Michael Snyder
2002-12-23 16:13   ` Daniel Jacobowitz
2002-12-23 16:59     ` Michael Snyder
2002-12-23 19:23       ` Daniel Jacobowitz
2003-01-02 20:25         ` Michael Snyder
2003-01-02 20:34           ` Elena Zannoni
2003-01-02 20:40             ` Michael Snyder
2003-01-03  0:12             ` Elena Zannoni [this message]
2003-01-03  1:44               ` Michael Snyder
2003-01-03  1:50                 ` Daniel Jacobowitz
2003-01-03  2:37                   ` Michael Snyder
2003-01-03 14:29                     ` Elena Zannoni
2003-01-03 23:51                       ` Michael Snyder
2003-01-03 23:53                         ` Elena Zannoni
2003-01-04  0:05                           ` Michael Snyder
2003-01-04  1:54                             ` Daniel Jacobowitz
2003-01-06 22:06                               ` Elena Zannoni
2003-01-07  1:27                                 ` Michael Snyder
2003-01-07  1:45                                   ` Elena Zannoni
2003-01-07  2:09                                     ` Michael Snyder
2003-01-07  4:31                                       ` Daniel Jacobowitz
2003-01-08 22:08                                         ` Elena Zannoni
2003-01-09  1:52                                           ` Daniel Jacobowitz
2003-01-10 22:25                                             ` Elena Zannoni
2003-01-10 22:28                                               ` Daniel Jacobowitz
2003-01-10 23:20                                                 ` Elena Zannoni
2003-01-03 14:15                   ` Elena Zannoni
2003-01-03 23:31                     ` Michael Snyder
2003-01-03 23:51                       ` Elena Zannoni
2003-01-03 23:58                         ` Michael Snyder
2003-01-03 14:13                 ` Elena Zannoni
2003-01-03 23:28                   ` Michael Snyder
2003-01-02 20:01       ` Elena Zannoni
2003-01-02 20:29         ` Michael Snyder
2003-01-03  4:15 Michael Elizabeth Chastain
2003-01-03  4:59 ` Daniel Jacobowitz
2003-01-03 21:52   ` Michael Snyder
2003-01-03 21:54     ` Daniel Jacobowitz
2003-01-03 22:39       ` Elena Zannoni
2003-01-03 23:09         ` Michael Snyder
2003-01-03 14:43 ` Elena Zannoni
2003-01-03 22:06   ` Michael Snyder
2003-01-03 22:43     ` Elena Zannoni
2003-01-03 23:13       ` Michael Snyder
2003-01-03  6:49 Michael Elizabeth Chastain
2003-01-03 15:17 ` Daniel Jacobowitz
2003-01-03 16:38 Michael Elizabeth Chastain
2003-01-03 16:57 ` Daniel Jacobowitz
2003-01-03 16:48 Michael Elizabeth Chastain
2003-01-03 23:33 ` Michael Snyder
2003-01-03 17:07 Michael Elizabeth Chastain
2003-01-03 17:51 ` Elena Zannoni
2003-01-03 17:40 Michael Elizabeth Chastain
2003-01-03 18:03 Michael Elizabeth Chastain
2003-01-04  0:37 Michael Elizabeth Chastain
2003-01-05 17:02 ` Andrew Cagney
2003-01-07  1:30   ` Michael Snyder
2003-01-07  3:53 Michael Elizabeth Chastain
2003-01-07  4:05 Michael Elizabeth Chastain
2003-01-11  1:04 Michael Elizabeth Chastain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15892.54871.381942.260248@localhost.redhat.com \
    --to=ezannoni@redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox