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

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, Jan 02, 2003 at 10:15:34PM -0600, Michael Elizabeth Chastain wrote:
> 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.

With a modern compiler, "after $PC" is pretty much meaningless.  Not
going to fly.  It could be re-ordered; there can be out-of-line code in
separate sections.

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

I like the idea of making "until LOCATION" work like "until".  I'd not
been exposed to this little beauty until this conversation made me go
examine the manual.  I don't see any reason for that to go to a
single-steppy behavior however.  And what it means when LOCATION is not
in function is not clear.  The problem is, do we know well enough when
LOCATION is or is not in FUNCTION to make any statements?

I'm not kidding about the out-of-line code thing.  I don't know if we
care about that, though; we ignore it everywhere else.  I don't want to
start making "after $PC" assumptions though.

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

After this discussion, I think I agree with the part of the behavior
you describe above.

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

The implicit breakpoint at the return is still somewhat useful, IMHO. 
It's not quite the same; when you hit one of the breakpoints (or stop
for some other reason), both vanish.  I don't think that's what tbreaks
do.

I'm still undecided about what to do if LOCATION is not in the
function.  Maybe you're right and we should make this an error.  What
if LOCATION is in the frame that called this one?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer