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

Elena Zannoni
2003-01-03T14:43:59Z

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