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

[Elena Zannoni <ezannoni at redhat dot com>]

Michael Snyder writes:
 > > > You raise a good point.  The commands "until <line>" and "until <func>"
 > > > are inconsistant.  Moreover the docs do not seem to describe this
 > > > recursion behavior.  Maybe a conversation with a wider audience is
 > > > in order (the gdb list)?  I'm sure I can't be the only one who
 > > > remembers that "until" behaved this way, and we shouldn't change
 > > > the behavior precipitously.
 > > 
 > > Am I the only one getting the feeling that we have two useful behaviors
 > > here; and that we should pick one for "until" but expose the other
 > > under some other name or with some option?
 > 
 > ;-)  That's often the case when someone feels 'intuitively' that 
 > gdb should behave differently.  We have to look out for feeping
 > creaturitis, but in this case I'm getting the impression that the
 > two behaviors are mutually incompatible, and may need to be separated
 > somehow.
 > 
 > If you say "until <line>", and the line is inside the current function,
 > you can impose the frame restriction.  If the line (or address) is outside 
 > the current function, or if you give a function name or something else, 
 > you can't.  And I don't think we can code that distinction at runtime.

I think we should come up with a behavior matrix, something like:

until: 
 continue until next source line is reached. If already at the last line
 of current function, continue until current frame pops.

until line:
 a. line in current function (1) --> continue until the line is reached.
 b. line in function in inner frame --> continue until the line is reached.
 c. line in function not in inner frame --> continue until current frame pops.

(1) However if current function is recursive, a. should become like
    b. But we want to enforce a different behavior, because we don't
    want to stop in the inner frame. --> this is the main problem,
    because the condition is basically impossible to figure out at run
    time.

until funcname:
 d. funcname called from current frame (2) --> continue until func is reached
 e. funcname not called from current frame --> cont until current frame pops.

(2) if current function is recursive and funcame == current function
    we want to stop at the next inner invocation of funcname


The 'continue until current frame pops' behavior is already there. It
always puts another bp_until at the caller.