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

[Michael Elizabeth Chastain <mec@shout.net>]

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.

  . 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

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.

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

From the Peanut Gallery,

Michael C