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

[Elena Zannoni <ezannoni at redhat dot com>]

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. 

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

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

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

 > >From the Peanut Gallery,
 > 
 > Michael C