Re: GDB Python API: stop/continue after breakpoint

[Kevin Pouget <kevin dot pouget at gmail dot 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
>>
>