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

[Michael Snyder <msnyder at redhat dot com>]

Elena Zannoni wrote:
> 
> Michael Elizabeth Chastain writes:
>  > 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).
> 
> See the thread from November on gdb@sources.
> 
>  >
>  > 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'.
>  >
> 
> Which tells me that the design was flawed.

'Design'?   ;-)


>  > How about this:
>  >
>  >   . require that LOCATION in 'until LOCATION' to be in the current
>  >     function and after $PC.  If it's not, then error.
>  >
>  >   . 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.
>  >
>  >   . change the manual to reflect this
>  >
> 
> Definitely the description in the manual needs more detail.  I prefer
> the until == tbreak behavior, which seems the most intuitive, given
> the replies to the November thread.
> 
> I think that using decode_line_1 may be the real problem, because that
> allows all kind of arguments to be used, just like for a breakpoint.

Well, but that's the stated intent.  Maybe it was over-ambitious?


>  > 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'.
>  >
>  > 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.
> 
> My case was when bar is recursive. you will execute the beginning of
> bar again, so 'until bar' would make sense in this case. I think this
> is what throws a wrench in the works.

What happens if you're at line 100 and you say "until 99"?


>  > 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'.
>  >
> 
> Don't know, I don't like it, but whatever we do we need to
> disambiguate the behavior. It's just plain confusing right now.

That it is, but forbidding usage that was formerly allowed
is just another way of changing the documented (or in this
case, un-documented) behavior.