This is the mail archive of the
mailing list for the GDB project.
Re: [RFA/PATCH] breakpoint.c: fix until command
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
> 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:
continue until next source line is reached. If already at the last line
of current function, continue until current frame pops.
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
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.