This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA/PATCH] breakpoint.c: fix until command
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: Michael Elizabeth Chastain <mec at shout dot net>
- Cc: drow at mvista dot com, msnyder at redhat dot com, ezannoni at redhat dot com, gdb-patches at sources dot redhat dot com
- Date: Fri, 3 Jan 2003 09:48:07 -0500
- Subject: Re: [RFA/PATCH] breakpoint.c: fix until command
- References: <200301030415.h034FYW05352@duracef.shout.net>
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