GDB Python API: stop/continue after breakpoint

GDB Python API: stop/continue after breakpoint

[Kevin Pouget]

Hello,

I've tried the GDB python interface today, which seems quite
efficient, but there is one important thing I couldn't figure out by
myself:

how to restart GDB when a[n internal] breakpoint is hit ?
from the testsuite I've got this code:

def breakpoint_stop_handler (event):
    if (isinstance (event, gdb.StopEvent)):
        print "event type: stop"
    if (isinstance (event, gdb.BreakpointEvent)):
        print "stop reason: breakpoint"
        print "breakpoint number: %s" % (event.breakpoint.number)
        if ( event.inferior_thread is not None) :
            print "thread num: %s" % (event.inferior_thread.num);
        else:
            print "all threads stopped"

gdb.events.stop.connect (breakpoint_stop_handler)


which where I get the notification of the stop, but I'd to be able to
tell GDB something like

enum bpstat_what_main_action {
    /* Remove breakpoints, single step once, then put them back in and
       go back to what we were doing.  It's possible that this should
       be removed from the main_action and put into a separate field,
       to more cleanly handle  BPSTAT_WHAT_CLEAR_LONGJMP_RESUME_SINGLE.  */
    BPSTAT_WHAT_SINGLE,
    /* Stop silently.  */
    BPSTAT_WHAT_STOP_SILENT,

    /* Stop and print.  */
    BPSTAT_WHAT_STOP_NOISY,
...
}

to continue silently, stop silently or print the breakpoint hit.

is it possible at this stage ?

Thanks,

Kevin

Re: GDB Python API: stop/continue after breakpoint

[Phil Muldoon]

Kevin Pouget <kevin.pouget@gmail.com> writes:

> Hello,
>
> I've tried the GDB python interface today, which seems quite
> efficient, but there is one important thing I couldn't figure out by
> myself:
>
> how to restart GDB when a[n internal] breakpoint is hit ?
> from the testsuite I've got this code:


You almost can. One part is pending:

http://sourceware.org/ml/gdb-patches/2011-03/msg00656.html

The implementation of the "stop" API.  The idea behind this is that if a
breakpoint is hit, that is tracked from Python and has an implemented
stop method, that method would be called.  You can do what you like in
that method.  If you want the inferior process to continue, return True
otherwise return False (and print out/do whatever else you need to do in
Python).

Because internal breakpoints are not tracked by default in the Python
Breakpoint API, you would have to create your breakpoint by
instantiating a gdb.Breakpoint class, and pass the keyword
internal=True.

So, long story short soon.  OTOH I'm not sure if there is a unhacky way
of doing it now.  You could use a convenience function, but that patch
is replacing that hacky way.

Cheers

Phil
>
> def breakpoint_stop_handler (event):
>     if (isinstance (event, gdb.StopEvent)):
>         print "event type: stop"
>     if (isinstance (event, gdb.BreakpointEvent)):
>         print "stop reason: breakpoint"
>         print "breakpoint number: %s" % (event.breakpoint.number)
>         if ( event.inferior_thread is not None) :
>             print "thread num: %s" % (event.inferior_thread.num);
>         else:
>             print "all threads stopped"
>
> gdb.events.stop.connect (breakpoint_stop_handler)
>
>
> which where I get the notification of the stop, but I'd to be able to
> tell GDB something like
>
> enum bpstat_what_main_action {
>     /* Remove breakpoints, single step once, then put them back in and
>        go back to what we were doing.  It's possible that this should
>        be removed from the main_action and put into a separate field,
>        to more cleanly handle  BPSTAT_WHAT_CLEAR_LONGJMP_RESUME_SINGLE.  */
>     BPSTAT_WHAT_SINGLE,
>     /* Stop silently.  */
>     BPSTAT_WHAT_STOP_SILENT,
>
>     /* Stop and print.  */
>     BPSTAT_WHAT_STOP_NOISY,
> ...
> }
>
> to continue silently, stop silently or print the breakpoint hit.
>
> is it possible at this stage ?
>
> Thanks,
>
> Kevin

Re: GDB Python API: stop/continue after breakpoint

[Kevin Pouget]

thanks for your answer, the patch seems to feature what I was looking for.

I'm a bit surprised that the stop/continue decision can't be done in
this breakpoint_stop handler, but I guess that was too complicated ?

> On Fri, Mar 11, 2011 at 5:25 PM, Phil Muldoon <pmuldoon@redhat.com> wrote:
>>
>> Kevin Pouget <kevin.pouget@gmail.com> writes:
>>
>> > Hello,
>> >
>> > I've tried the GDB python interface today, which seems quite
>> > efficient, but there is one important thing I couldn't figure out by
>> > myself:
>> >
>> > how to restart GDB when a[n internal] breakpoint is hit ?
>> > from the testsuite I've got this code:
>>
>>
>> You almost can. One part is pending:
>>
>> http://sourceware.org/ml/gdb-patches/2011-03/msg00656.html
>>
>> The implementation of the "stop" API.  The idea behind this is that if a
>> breakpoint is hit, that is tracked from Python and has an implemented
>> stop method, that method would be called.  You can do what you like in
>> that method.  If you want the inferior process to continue, return True
>> otherwise return False (and print out/do whatever else you need to do in
>> Python).
>>
>> Because internal breakpoints are not tracked by default in the Python
>> Breakpoint API, you would have to create your breakpoint by
>> instantiating a gdb.Breakpoint class, and pass the keyword
>> internal=True.
>>
>> So, long story short soon.  OTOH I'm not sure if there is a unhacky way
>> of doing it now.  You could use a convenience function, but that patch
>> is replacing that hacky way.
>>
>> Cheers
>>
>> Phil
>> >
>> > def breakpoint_stop_handler (event):
>> >     if (isinstance (event, gdb.StopEvent)):
>> >         print "event type: stop"
>> >     if (isinstance (event, gdb.BreakpointEvent)):
>> >         print "stop reason: breakpoint"
>> >         print "breakpoint number: %s" % (event.breakpoint.number)
>> >         if ( event.inferior_thread is not None) :
>> >             print "thread num: %s" % (event.inferior_thread.num);
>> >         else:
>> >             print "all threads stopped"
>> >
>> > gdb.events.stop.connect (breakpoint_stop_handler)
>> >
>> >
>> > which where I get the notification of the stop, but I'd to be able to
>> > tell GDB something like
>> >
>> > enum bpstat_what_main_action {
>> >     /* Remove breakpoints, single step once, then put them back in and
>> >        go back to what we were doing.  It's possible that this should
>> >        be removed from the main_action and put into a separate field,
>> >        to more cleanly handle  BPSTAT_WHAT_CLEAR_LONGJMP_RESUME_SINGLE.  */
>> >     BPSTAT_WHAT_SINGLE,
>> >     /* Stop silently.  */
>> >     BPSTAT_WHAT_STOP_SILENT,
>> >
>> >     /* Stop and print.  */
>> >     BPSTAT_WHAT_STOP_NOISY,
>> > ...
>> > }
>> >
>> > to continue silently, stop silently or print the breakpoint hit.
>> >
>> > is it possible at this stage ?
>> >
>> > Thanks,
>> >
>> > Kevin
>

Re: GDB Python API: stop/continue after breakpoint

[Kevin Pouget]

cool, that's working perfectly now !

just one thing:

> <python breakpoint outputs>
>
> [Switching to Thread 0x7ffff7de1700 (LWP 2417)]
>
> Breakpoint -9, rdb_notify_event () at replay_db.c:11
> 11	void rdb_notify_event() {}

is there any way / woudn't it be nice to have the ability to disable
the breakpoint hit outputs? at least for the 'internal' breakpoints,
which shouldn't be visible to the user ?

Thanks,

Kevin

On Fri, Mar 11, 2011 at 11:25 AM, Phil Muldoon <pmuldoon@redhat.com> wrote:
>
> Kevin Pouget <kevin.pouget@gmail.com> writes:
>
> > Hello,
> >
> > I've tried the GDB python interface today, which seems quite
> > efficient, but there is one important thing I couldn't figure out by
> > myself:
> >
> > how to restart GDB when a[n internal] breakpoint is hit ?
> > from the testsuite I've got this code:
>
>
> You almost can. One part is pending:
>
> http://sourceware.org/ml/gdb-patches/2011-03/msg00656.html
>
> The implementation of the "stop" API.  The idea behind this is that if a
> breakpoint is hit, that is tracked from Python and has an implemented
> stop method, that method would be called.  You can do what you like in
> that method.  If you want the inferior process to continue, return True
> otherwise return False (and print out/do whatever else you need to do in
> Python).
>
> Because internal breakpoints are not tracked by default in the Python
> Breakpoint API, you would have to create your breakpoint by
> instantiating a gdb.Breakpoint class, and pass the keyword
> internal=True.
>
> So, long story short soon.  OTOH I'm not sure if there is a unhacky way
> of doing it now.  You could use a convenience function, but that patch
> is replacing that hacky way.
>
> Cheers
>
> Phil
> >
> > def breakpoint_stop_handler (event):
> >     if (isinstance (event, gdb.StopEvent)):
> >         print "event type: stop"
> >     if (isinstance (event, gdb.BreakpointEvent)):
> >         print "stop reason: breakpoint"
> >         print "breakpoint number: %s" % (event.breakpoint.number)
> >         if ( event.inferior_thread is not None) :
> >             print "thread num: %s" % (event.inferior_thread.num);
> >         else:
> >             print "all threads stopped"
> >
> > gdb.events.stop.connect (breakpoint_stop_handler)
> >
> >
> > which where I get the notification of the stop, but I'd to be able to
> > tell GDB something like
> >
> > enum bpstat_what_main_action {
> >     /* Remove breakpoints, single step once, then put them back in and
> >        go back to what we were doing.  It's possible that this should
> >        be removed from the main_action and put into a separate field,
> >        to more cleanly handle  BPSTAT_WHAT_CLEAR_LONGJMP_RESUME_SINGLE.  */
> >     BPSTAT_WHAT_SINGLE,
> >     /* Stop silently.  */
> >     BPSTAT_WHAT_STOP_SILENT,
> >
> >     /* Stop and print.  */
> >     BPSTAT_WHAT_STOP_NOISY,
> > ...
> > }
> >
> > to continue silently, stop silently or print the breakpoint hit.
> >
> > is it possible at this stage ?
> >
> > Thanks,
> >
> > Kevin

Re: GDB Python API: stop/continue after breakpoint

[Phil Muldoon]

Kevin Pouget <kevin.pouget@gmail.com> writes:

> cool, that's working perfectly now !
>
> just one thing:
>
>> <python breakpoint outputs>
>>
>> [Switching to Thread 0x7ffff7de1700 (LWP 2417)]
>>
>> Breakpoint -9, rdb_notify_event () at replay_db.c:11
>> 11	void rdb_notify_event() {}
>
> is there any way / woudn't it be nice to have the ability to disable
> the breakpoint hit outputs? at least for the 'internal' breakpoints,
> which shouldn't be visible to the user ?

You can set the breakpoint to silent:

(gdb) python b = gdb.Breakpoint("hello.c:5", internal=True)
(gdb) run
Breakpoint -1, main () at /home/pmuldoon/hello.c:5
5	  printf("Hello world!\n");
(gdb) py b.silent = True
(gdb) run
(gdb) list
(gdb) where
#0  main () at /home/pmuldoon/hello.c:5

There might be a case for setting the breakpoint to 'silent' in the
breakpoint constructor:

python b = gdb.Breakpoint("hello.c:5", internal=True, silent=True)

or just making internal breakpoints silent by default.

I'll implement either.  What do you think?

Cheers,

Phil

Re: GDB Python API: stop/continue after breakpoint

[Kevin Pouget]

> (gdb) py b.silent = True

very nice! I was just reading an old post
http://sourceware.org/ml/gdb/2007-04/msg00127.html about a plugin vs
scripting interface, Python finally get the point, it's now easier to
write a Python script which handles breakpoints than a GDB patch!

> There might be a case for setting the breakpoint to 'silent' in the
> breakpoint constructor:
>
> python b = gdb.Breakpoint("hello.c:5", internal=True, silent=True)
>
> or just making internal breakpoints silent by default.
>
> I'll implement either.  What do you think?

from my perspective, _internal breakpoints_ should be silent by
default, because they're 'internal', as their name says.

Option 1) is quite similar `b.silent`, so it's up to you


Cordially,

Kevin

Re: GDB Python API: stop/continue after breakpoint

[Kevin Pouget]

Hello,

I'm coming back to this post because I've got a bit of an issue here:

basically, I need (and I'm looking for to helping for it!) a sharp
control of the inferior execution from the python interface, but I'm
facing some limitations:

* in MyBreakpoint.stop(), I can say continue/stop the inferior, but I
can't run "finish" (or "next" or what ever, I guess), because the
inferior is still considered as running:
> "gdb.error: Cannot execute this command while the selected thread is running."

* in event.stop.connect() that's possible, but I can't
`gdb.execute("continue")' the execution because I would miss any
"non-python" reasons to stop (ie, a user-breakpoint, a signal ...)

let me know if my problem is not clear, and if you have any comment /
idea on how to solve it


cordially,

Kevin

On Fri, Mar 11, 2011 at 12:52 PM, Kevin Pouget <kevin.pouget@gmail.com> wrote:
> thanks for your answer, the patch seems to feature what I was looking for.
>
> I'm a bit surprised that the stop/continue decision can't be done in
> this breakpoint_stop handler, but I guess that was too complicated ?
>
>> On Fri, Mar 11, 2011 at 5:25 PM, Phil Muldoon <pmuldoon@redhat.com> wrote:
>>>
>>> Kevin Pouget <kevin.pouget@gmail.com> writes:
>>>
>>> > Hello,
>>> >
>>> > I've tried the GDB python interface today, which seems quite
>>> > efficient, but there is one important thing I couldn't figure out by
>>> > myself:
>>> >
>>> > how to restart GDB when a[n internal] breakpoint is hit ?
>>> > from the testsuite I've got this code:
>>>
>>>
>>> You almost can. One part is pending:
>>>
>>> http://sourceware.org/ml/gdb-patches/2011-03/msg00656.html
>>>
>>> The implementation of the "stop" API.  The idea behind this is that if a
>>> breakpoint is hit, that is tracked from Python and has an implemented
>>> stop method, that method would be called.  You can do what you like in
>>> that method.  If you want the inferior process to continue, return True
>>> otherwise return False (and print out/do whatever else you need to do in
>>> Python).
>>>
>>> Because internal breakpoints are not tracked by default in the Python
>>> Breakpoint API, you would have to create your breakpoint by
>>> instantiating a gdb.Breakpoint class, and pass the keyword
>>> internal=True.
>>>
>>> So, long story short soon.  OTOH I'm not sure if there is a unhacky way
>>> of doing it now.  You could use a convenience function, but that patch
>>> is replacing that hacky way.
>>>
>>> Cheers
>>>
>>> Phil
>>> >
>>> > def breakpoint_stop_handler (event):
>>> >     if (isinstance (event, gdb.StopEvent)):
>>> >         print "event type: stop"
>>> >     if (isinstance (event, gdb.BreakpointEvent)):
>>> >         print "stop reason: breakpoint"
>>> >         print "breakpoint number: %s" % (event.breakpoint.number)
>>> >         if ( event.inferior_thread is not None) :
>>> >             print "thread num: %s" % (event.inferior_thread.num);
>>> >         else:
>>> >             print "all threads stopped"
>>> >
>>> > gdb.events.stop.connect (breakpoint_stop_handler)
>>> >
>>> >
>>> > which where I get the notification of the stop, but I'd to be able to
>>> > tell GDB something like
>>> >
>>> > enum bpstat_what_main_action {
>>> >     /* Remove breakpoints, single step once, then put them back in and
>>> >        go back to what we were doing.  It's possible that this should
>>> >        be removed from the main_action and put into a separate field,
>>> >        to more cleanly handle  BPSTAT_WHAT_CLEAR_LONGJMP_RESUME_SINGLE.  */
>>> >     BPSTAT_WHAT_SINGLE,
>>> >     /* Stop silently.  */
>>> >     BPSTAT_WHAT_STOP_SILENT,
>>> >
>>> >     /* Stop and print.  */
>>> >     BPSTAT_WHAT_STOP_NOISY,
>>> > ...
>>> > }
>>> >
>>> > to continue silently, stop silently or print the breakpoint hit.
>>> >
>>> > is it possible at this stage ?
>>> >
>>> > Thanks,
>>> >
>>> > Kevin
>>
>

Re: GDB Python API: stop/continue after breakpoint

[Phil Muldoon]

Kevin Pouget <kevin.pouget@gmail.com> writes:

> Hello,
>
> I'm coming back to this post because I've got a bit of an issue here:
>
> basically, I need (and I'm looking for to helping for it!) a sharp
> control of the inferior execution from the python interface, but I'm
> facing some limitations:
>
> * in MyBreakpoint.stop(), I can say continue/stop the inferior, but I
> can't run "finish" (or "next" or what ever, I guess), because the
> inferior is still considered as running:
>> "gdb.error: Cannot execute this command while the selected thread is running."

At this point GDB is deciding whether to stop the inferior and
return control to the console or not.  (Really, at this point, the
inferior is stopped, by ptrace, but GDB is trying to work out if it
should really maintain the stop, or resume the inferior).  So in GDB's
internal data store, the inferior (thread) is still "running" and will
be so until a firm stop decision is reached.  Because of this
intermediate state, you cannot issue cannot step/next/continue/finish or
other inferior control commands.  This is really a very simplistic view
of what is going on.  I've glossed over a lot.


> * in event.stop.connect() that's possible, but I can't
> `gdb.execute("continue")' the execution because I would miss any
> "non-python" reasons to stop (ie, a user-breakpoint, a signal ...)

The only thing I can think to do here is set some of your own data in
your Python module.  Breakpoint.stop sets some flag or data, and the
event.connect can pick up on that. But there are gaps in the API.  File
bugs, I look there daily. 

I hope this helped some!

Cheers,

Phil

Re: GDB Python API: stop/continue after breakpoint

[Tom Tromey]

>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:

Sorry, I didn't notice this until your follow-up.

Kevin> thanks for your answer, the patch seems to feature what I was
Kevin> looking for.  I'm a bit surprised that the stop/continue decision
Kevin> can't be done in this breakpoint_stop handler, but I guess that
Kevin> was too complicated ?

We intentionally made event handlers not return values.

My recollection is that this was done both due to simplicity and also
out of the desire to make it clear that event handlers ought to be
logically separate.  Once handlers affect other handlers, the coding
gets more complicated, and it seems better to associate such actions
more directly with their causes.

Tom

Re: GDB Python API: stop/continue after breakpoint

[Tom Tromey]

>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:

Kevin> * in MyBreakpoint.stop(), I can say continue/stop the inferior, but I
Kevin> can't run "finish" (or "next" or what ever, I guess), because the
Kevin> inferior is still considered as running:

I think it would be pretty difficult to get this to work.

Kevin> * in event.stop.connect() that's possible, but I can't
Kevin> `gdb.execute("continue")' the execution because I would miss any
Kevin> "non-python" reasons to stop (ie, a user-breakpoint, a signal ...)

I think you should be able to examine the stop event object to see what
caused the event.  If the event is a gdb.BreakpointEvent, and if
event.breakpoint is your breakpoint, then do what you want.

Tom

Re: GDB Python API: stop/continue after breakpoint

[Kevin Pouget]

> Kevin> * in event.stop.connect() that's possible, but I can't
> Kevin> `gdb.execute("continue")' the execution because I would miss any
> Kevin> "non-python" reasons to stop (ie, a user-breakpoint, a signal ...)
>
> I think you should be able to examine the stop event object to see what
> caused the event.  If the event is a gdb.BreakpointEvent, and if
> event.breakpoint is your breakpoint, then do what you want.

I'm afraid that's impossible to do it with the current implementation, look:

def handle_double_stop(event):
	print "Stop event: ", event.breakpoint.number
gdb.events.stop.connect(handle_double_stop)

(gdb) break main
Breakpoint 1
(gdb) break main
Breakpoint 2
(gdb) run
Stop event: 1

... as far as I know, there is no 'easy' way to know that Bp 2 was hit as well

Re: GDB Python API: stop/continue after breakpoint

[Kevin Pouget]

before I start any implementation, would you agree if I change

> int
> emit_stop_event (struct bpstats *bs, enum target_signal stop_signal)
> ...
>  if (bs && bs->breakpoint_at
>      && bs->breakpoint_at->py_bp_object)
>    {
>      stop_event_obj = create_breakpoint_event_object ((PyObject *) bs
>                                                       ->breakpoint_at
>                                                       ->py_bp_object);
>    }

so that it browses the `bs->next' list  and returns a python tuple
instead of a single object ?

>     /* Linked list because there can be more than one breakpoint at
>        the same place, and a bpstat reflects the fact that all have
>        been hit.  */
>     bpstat next;


Cordially,

Kevin

On Thu, Apr 21, 2011 at 9:01 AM, Kevin Pouget <kevin.pouget@gmail.com> wrote:
>> Kevin> * in event.stop.connect() that's possible, but I can't
>> Kevin> `gdb.execute("continue")' the execution because I would miss any
>> Kevin> "non-python" reasons to stop (ie, a user-breakpoint, a signal ...)
>>
>> I think you should be able to examine the stop event object to see what
>> caused the event.  If the event is a gdb.BreakpointEvent, and if
>> event.breakpoint is your breakpoint, then do what you want.
>
> I'm afraid that's impossible to do it with the current implementation, look:
>
> def handle_double_stop(event):
>        print "Stop event: ", event.breakpoint.number
> gdb.events.stop.connect(handle_double_stop)
>
> (gdb) break main
> Breakpoint 1
> (gdb) break main
> Breakpoint 2
> (gdb) run
> Stop event: 1
>
> ... as far as I know, there is no 'easy' way to know that Bp 2 was hit as well
>