Re: GDB Python API: stop/continue after breakpoint

[Kevin Pouget <kevin.pouget@gmail.com>]

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
>>
>