Breakpoint commands

Breakpoint commands

[Eli Zaretskii]

Some commands seem to be not working inside breakpoint commands, in
the sense that breakpoint commands after them are not executed.

Two examples that I tried were `finish' and `until'.  What I wanted
was to stop at function entry, print some variable, then let the
function run to completion, and print some other (global) variable
that gets modified by this function.  The breakpoint commands
therefore were something like

  break FOO
  commands
  >print BAR
  >finish
  >print BAZ
  >end

and similarly with `until' instead of `finish'; I used the last line
of the function's body for its argument.

What I see is that the second `print' is never executed.  Sounds like
a bug to me.  Or did I miss something?

Re: Breakpoint commands

[Pedro Alves]

A Saturday 24 October 2009 15:12:41, Eli Zaretskii escreveu:
> Some commands seem to be not working inside breakpoint commands, in
> the sense that breakpoint commands after them are not executed.
> 
> Two examples that I tried were `finish' and `until'.  What I wanted
> was to stop at function entry, print some variable, then let the
> function run to completion, and print some other (global) variable
> that gets modified by this function.  The breakpoint commands
> therefore were something like
> 
>   break FOO
>   commands
>   >print BAR
>   >finish
>   >print BAZ
>   >end
> 
> and similarly with `until' instead of `finish'; I used the last line
> of the function's body for its argument.
> 
> What I see is that the second `print' is never executed.  Sounds like
> a bug to me.  Or did I miss something?
> 

From gdb.texinfo:'Break Commands':

"You can use breakpoint commands to start your program up again.  Simply
use the @code{continue} command, or @code{step}, or any other command
that resumes execution.

Any other commands in the command list, after a command that resumes
execution, are ignored.  This is because any time you resume execution
(even with a simple @code{next} or @code{step}), you may encounter
another breakpoint---which could have its own command list, leading to
ambiguities about which list to execute."

-- 
Pedro Alves

Re: Breakpoint commands

[Eli Zaretskii]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Sat, 24 Oct 2009 17:03:59 +0100
> 
> "You can use breakpoint commands to start your program up again.  Simply
> use the @code{continue} command, or @code{step}, or any other command
> that resumes execution.
> 
> Any other commands in the command list, after a command that resumes
> execution, are ignored.  This is because any time you resume execution
> (even with a simple @code{next} or @code{step}), you may encounter
> another breakpoint---which could have its own command list, leading to
> ambiguities about which list to execute."

Thanks for reminding me.  We ought to display a warning when any
commands are used on the command list beyond those which resume.

Re: Breakpoint commands

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Some commands seem to be not working inside breakpoint commands, in
> the sense that breakpoint commands after them are not executed.

*Note (gdb) Break Commands::
   Any other commands in the command list, after a command that resumes
execution, are ignored.  This is because any time you resume execution
(even with a simple `next' or `step'), you may encounter another
breakpoint--which could have its own command list, leading to
ambiguities about which list to execute.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Breakpoint commands

[Paul Pluzhnikov]

On Sat, Oct 24, 2009 at 9:30 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Pedro Alves <pedro@codesourcery.com>
>> Date: Sat, 24 Oct 2009 17:03:59 +0100
>>
>> "You can use breakpoint commands to start your program up again.  Simply
>> use the @code{continue} command, or @code{step}, or any other command
>> that resumes execution.
>>
>> Any other commands in the command list, after a command that resumes
>> execution, are ignored.  This is because any time you resume execution
>> (even with a simple @code{next} or @code{step}), you may encounter
>> another breakpoint---which could have its own command list, leading to
>> ambiguities about which list to execute."
>
> Thanks for reminding me.  We ought to display a warning when any
> commands are used on the command list beyond those which resume.

FWIW, I very often would like to do this:

  int foo(int x) { ... }

break foo
command 1
print x
finish  ## expecting it to print return of foo()
continue

and that last 'continue' of course doesn't work, so I have to sit an
press enter all day :-(

The argument of "you may encounter other breakpoints ..." is (IMHO) a
weak one: I *don't* in fact encounter any other breakpoints.

It's probably not too difficult to implement "if you encounter any
other breakpoint with its own command list while executing the
original command list, the original command list is abandoned" policy.
I'll open a feature request unless somebody explains why this would be
a bad idea.

Thanks,
-- 
Paul Pluzhnikov

Re: Breakpoint commands

[Michael Snyder]

Paul Pluzhnikov wrote:
> On Sat, Oct 24, 2009 at 9:30 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Pedro Alves <pedro@codesourcery.com>
>>> Date: Sat, 24 Oct 2009 17:03:59 +0100
>>>
>>> "You can use breakpoint commands to start your program up again.  Simply
>>> use the @code{continue} command, or @code{step}, or any other command
>>> that resumes execution.
>>>
>>> Any other commands in the command list, after a command that resumes
>>> execution, are ignored.  This is because any time you resume execution
>>> (even with a simple @code{next} or @code{step}), you may encounter
>>> another breakpoint---which could have its own command list, leading to
>>> ambiguities about which list to execute."
>> Thanks for reminding me.  We ought to display a warning when any
>> commands are used on the command list beyond those which resume.
> 
> FWIW, I very often would like to do this:
> 
>   int foo(int x) { ... }
> 
> break foo
> command 1
> print x
> finish  ## expecting it to print return of foo()
> continue
> 
> and that last 'continue' of course doesn't work, so I have to sit an
> press enter all day :-(
> 
> The argument of "you may encounter other breakpoints ..." is (IMHO) a
> weak one: I *don't* in fact encounter any other breakpoints.

I think the "argument" that you may encounter other breakpoints
is in part a rationalization.  In reality, it seems to me that
we just didn't want to make breakpoint command handling (which
would have included handle_inferior_event) recursive.


> It's probably not too difficult to implement "if you encounter any
> other breakpoint with its own command list while executing the
> original command list, the original command list is abandoned" policy.
> I'll open a feature request unless somebody explains why this would be
> a bad idea.
> 
> Thanks,

Re: Breakpoint commands

[Joel Brobecker]

> It's probably not too difficult to implement "if you encounter any
> other breakpoint with its own command list while executing the
> original command list, the original command list is abandoned" policy.
> I'll open a feature request unless somebody explains why this would be
> a bad idea.

I think it would indeed be a big improvement.  I was hoping that the issue
would go away with python support, but anyone who learnt about this behavior
was surprised and found the argument to be very weak.

-- 
Joel

Re: Breakpoint commands

[Vladimir Prus]

Joel Brobecker wrote:

>> It's probably not too difficult to implement "if you encounter any
>> other breakpoint with its own command list while executing the
>> original command list, the original command list is abandoned" policy.
>> I'll open a feature request unless somebody explains why this would be
>> a bad idea.
> 
> I think it would indeed be a big improvement.  I was hoping that the issue
> would go away with python support, but anyone who learnt about this behavior
> was surprised and found the argument to be very weak.

I'd like to mention this is not the only case where GDB abandons something
when hitting something else. E.g. if you have solib events enabled, and do
next and solib is loaded, the "next" operation is aborted, and you're stuck
in the middle of nowhere with no chance for a frontend to do anything.

It would be nice of infrun be rewritten to use a proper state machine, permitting
nesting.

- Volodya

Re: Breakpoint commands

[Paul Pluzhnikov]

Everybody, thanks for input.

Feature request filed:
http://sourceware.org/bugzilla/show_bug.cgi?id=10852

-- 
Paul Pluzhnikov