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
Elena Zannoni wrote:
>
> Michael Snyder writes:
> > Elena Zannoni wrote:
> > >
> > > 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.
> >
> > 'Design'? ;-)
> >
> >
> > > > 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.
> >
> > Well, but that's the stated intent. Maybe it was over-ambitious?
> >
>
> very likely so. If you accept the arguments that 'break' accepts, then
> 'until foo' should do something meaningful. Otherwise, why go through
> the effort. Apparently they thought it did something useful. I tried
> to build 4.16 but I cannot find a host where it builds. Maybe it
> really worked both ways back then?
I confess that it never occurred to me to say "until foo".
> > > > 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.
> >
> > What happens if you're at line 100 and you say "until 99"?
> >
>
> Well, you could be at the last line in the body of a loop, and you may
> want to go to the first line of the body of the loop, for instance. So
> you cannot discharge that.
The question I meant to ask was "what does it currently/traditionally do?",
but if you're thinking of "what _should_ it do", that's a good question too.
> > > > 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.
> >
> > That it is, but forbidding usage that was formerly allowed
> > is just another way of changing the documented (or in this
> > case, un-documented) behavior.
>
> Well, the recursive behavior is the one that is undocumented. Look at
> the output of 'help until'. I think somebody was sniffing something
> powerful that day.
I know, I know...
It could be me, since so far I seem to be the only one who
remembers it that way... but damned if I don't seem to remember
reading about it in a comment -- probably in breakpoint.c.