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

[Michael Snyder <msnyder@redhat.com>]

Elena Zannoni wrote:
> 
> Michael Snyder writes:
>  > 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?
>  >
> 
> very likely so. If you accept the arguments that 'break' accepts, then
> 'until foo' should do something meaningful. Otherwise, why go through
> the effort. Apparently they thought it did something useful. I tried
> to build 4.16 but I cannot find a host where it builds. Maybe it
> really worked both ways back then?

I confess that it never occurred to me to say "until foo".


>  > >  > 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"?
>  >
> 
> Well, you could be at the last line in the body of a loop, and you may
> want to go to the first line of the body of the loop, for instance. So
> you cannot discharge that.

The question I meant to ask was "what does it currently/traditionally do?",
but if you're thinking of "what _should_ it do", that's a good question too.

>  > >  > 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.
> 
> Well, the recursive behavior is the one that is undocumented. Look at
> the output of 'help until'. I think somebody was sniffing something
> powerful that day.

I know, I know...
It could be me, since so far I seem to be the only one who
remembers it that way... but damned if I don't seem to remember
reading about it in a comment -- probably in breakpoint.c.