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

[Elena Zannoni <ezannoni at redhat dot com>]

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?

 > 
 > >  > 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. 

 > 
 > >  > 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.

Elena