[Bug breakpoints/10852] New: command sequences interrupted unexpectedly

["ppluzhnikov at google dot com" <sourceware-bugzilla at sourceware dot org>]

Original thread: http://sourceware.org/ml/gdb/2009-10/msg00349.html


From: Eli Zaretskii <eliz@gnu.org>
Date: Sat, Oct 24, 2009 at 7:12 AM
To: gdb@sourceware.org


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: Pedro Alves <pedro@codesourcery.com>
Date: Sat, Oct 24, 2009 at 9:03 AM
To: gdb@sourceware.org, Eli Zaretskii <eliz@gnu.org>


A Saturday 24 October 2009 15:12:41, Eli Zaretskii escreveu:
>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."

----------
From: Paul Pluzhnikov <ppluzhnikov@google.com>
Date: Sat, Oct 24, 2009 at 12:29 PM
To: Eli Zaretskii <eliz@gnu.org>
Cc: Pedro Alves <pedro@codesourcery.com>, gdb@sourceware.org


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.

----------
From: Michael Snyder <msnyder@vmware.com>
Date: Sat, Oct 24, 2009 at 3:58 PM
To: Paul Pluzhnikov <ppluzhnikov@google.com>
Cc: Eli Zaretskii <eliz@gnu.org>, Pedro Alves <pedro@codesourcery.com>,
"gdb@sourceware.org" <gdb@sourceware.org>


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.

----------
From: Joel Brobecker <brobecker@adacore.com>
Date: Mon, Oct 26, 2009 at 2:59 AM
To: Paul Pluzhnikov <ppluzhnikov@google.com>
Cc: Eli Zaretskii <eliz@gnu.org>, Pedro Alves <pedro@codesourcery.com>,
gdb@sourceware.org


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.

----------
From: Vladimir Prus <vladimir@codesourcery.com>
Date: Mon, Oct 26, 2009 at 4:30 AM
To: gdb@sources.redhat.com


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.

-- 
           Summary: command sequences interrupted unexpectedly
           Product: gdb
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: breakpoints
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: ppluzhnikov at google dot com
                CC: gdb-prs at sourceware dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.