This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: What is "until" supposed to do?


> Date: Wed, 23 Feb 2005 11:23:30 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> The comment in infcmd.c:until_next_command says:
> 
> /* Proceed until we reach a different source line with pc greater than
>    our current one or exit the function.  We skip calls in both cases.
> 
>    Note that eventually this command should probably be changed so
>    that only source lines are printed out when we hit the breakpoint
>    we set.  This may involve changes to wait_for_inferior and the
>    proceed status code.  */
> 
> The documentation says:
> 
>      Continue running until a source line past the current line, in the
>      current stack frame, is reached.  This command is used to avoid
>      single stepping through a loop more than once.  It is like the
>      `next' command, except that when `until' encounters a jump, it
>      automatically continues execution until the program counter is
>      greater than the address of the jump.
> 
>      This means that when you reach the end of a loop after single
>      stepping though it, `until' makes your program continue execution
>      until it exits the loop.  In contrast, a `next' command at the end
>      of a loop simply steps back to the beginning of the loop, which
>      forces you to step through the next iteration.
> 
> But then the documentation goes on to give an example that agrees with the
> comment in until_next_command; it's about a PC greater than the current PC,
> not a source line "past" the current line.  If the test at the end of a loop
> has the line number of the beginning of the loop, an "until" at the end of
> the loop will go to the earlier source line, and another "until" will take
> you out of the loop (wow, there's lots of room for basic block reordering to
> break this command...).
> 
> I think that the example and comment are correct, and only the documentation
> is wrong (or at least confusing).  I'm not sure how to reword it though...

First, I vaguely recollect that we had a discussion about this,
although I couldn't find it (and thus might say below something that
was already discussed and addressed).

Basically, I think that the documentation, up until the point where it
talks about ``counter-intuitive results'', is correct, and the
implementation is buggy or at least less than perfect.  `until' is a
source-level command, so IMHO it doesn't make sense to define it in
terms of the value of PC: users who debug at the source level don't
care about PC, they care about source lines.

So it would be best if `until' indeed did what the manual says:
single-step the program until the place in the code which corresponds
to the next source line.  If, due to optimizations, the next source
line corresponds to the smaller value of PC, we should do something
reasonable, like perhaps warn the user or maybe step until the first
source line whose PC is greater.  In any case, it certainly does NOT
make any sense to wind up at a source line with a smaller number, like
in the example you bumped into:

>   while (i < 2)
>     i++;
> The ARM compiler I am testing marks the jump after the increment as being
> associated with the first line of the loop rather than the second, which
> makes good sense

Well, to me, such behavior doesn't make any good sense.  It actually
defeats the very reason for using `until' in this case: the user wants
to get past the loop!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]