Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder <msnyder at redhat dot com>]

Daniel Jacobowitz wrote:
> 
> On Thu, Jan 02, 2003 at 10:15:34PM -0600, Michael Elizabeth Chastain wrote:
> > I think the problem is inherent in the design.  'until' with no argument
> > is meant for getting past loops in the current stack frame.  (The manual
> > says that).  So it makes sense that it skips over all subroutine calls
> > and also stops if the current stack frame inadvertently exits before
> > getting past the end of a loop.
> >
> > 'until LOCATION' is quite different.  The manual says:
> >
> >   `until LOCATION'
> >   `u LOCATION'
> >        Continue running your program until either the specified location
> >        is reached, or the current stack frame returns.  LOCATION is any of
> >        the forms of argument acceptable to `break' (*note Setting
> >        breakpoints: Set Breaks).  This form of the command uses
> >        breakpoints, and hence is quicker than `until' without an argument.
> >
> > Read this way, it looks like 'until LOCATION' is mostly a synonym for
> > 'tbreak LOCATION; continue', with one extra tbreak at the return address
> > in the superior frame.  (break.exp says as much but they forgot about
> > the case where the current stack frame returns).
> >
> > I think this is bad.  We already have 'tbreak'.  I think it's weird and
> > redundant to have another 'until LOCATION' which is a lot like 'tbreak'
> > and not much like 'until'.
> >
> > Also I trust Michael Snyder's interpretation of the original intent more
> > than this particular section of The Fine Manual.  It's bad when the manual
> > talks about the implementation of both 'until' and 'until LOCATION' and
> > points out that they are different.  It implies that the original designers
> > knew they had some inconsistency between 'until' and 'until LOCATION'.
> >
> > How about this:
> >
> >   . require that LOCATION in 'until LOCATION' to be in the current
> >     function and after $PC.  If it's not, then error.
> 
> With a modern compiler, "after $PC" is pretty much meaningless.  Not
> going to fly.  It could be re-ordered; there can be out-of-line code in
> separate sections.
> 
> >   . use the same steppy implementation for 'until LOCATION' as 'until',
> >     not a breakpointy implementation.  In fact, 'until' with no arguments
> >     simply becomes 'until LOCATION' where gdb picks a location by default.
> 
> I like the idea of making "until LOCATION" work like "until".  I'd not
> been exposed to this little beauty until this conversation made me go
> examine the manual.  I don't see any reason for that to go to a
> single-steppy behavior however.  And what it means when LOCATION is not
> in function is not clear.  The problem is, do we know well enough when
> LOCATION is or is not in FUNCTION to make any statements?
> 
> I'm not kidding about the out-of-line code thing.  I don't know if we
> care about that, though; we ignore it everywhere else.  I don't want to
> start making "after $PC" assumptions though.
> 
> >   . change the manual to reflect this
> >
> > Specifically, in Elena's case of the factorial: if the user wants to
> > stop at line 99 in ANY frame, they can use 'tbreak 99' or 'break 99'.
> > If the user wants to stop at line 99 in the CURRENT frame, they can use
> > 'until 99'.
> 
> After this discussion, I think I agree with the part of the behavior
> you describe above.
> 
> > And in Elena's second case: what if you are in 'bar' at the moment and you
> > say 'until bar'?  I think that should be an error, because 'bar' is in
> > the current function, but it is not after $PC.
> >
> > Similarly if you are currently in 'bar' and say 'until quux'.  Just error it.
> > Don't turn it into a tbreak.
> >
> > This would make both forms of 'until' behave the same, all the time.
> > The user can still do whatever they want.  Want to progress a little in
> > the same frame?  Call 'until', with or without an argument.  Want to be
> > somewhere and not care if the frames change?  Call 'break' or 'tbreak'.
> 
> The implicit breakpoint at the return is still somewhat useful, IMHO.
> It's not quite the same; when you hit one of the breakpoints (or stop
> for some other reason), both vanish.  I don't think that's what tbreaks
> do.
> 
> I'm still undecided about what to do if LOCATION is not in the
> function.  Maybe you're right and we should make this an error.  What
> if LOCATION is in the frame that called this one?

My thoughts have run in similar grooves.  ;-)
The sticking point is "is <location> in the current function?"
I believe we can answer that, by calling find_pc_partial_function.
That will give us the function's address range, and we can then
immediately determine whether <location> is in (use frame-relative bp),
or out (don't do that).

Michael