GDB Python API: stop/continue after breakpoint
Kevin Pouget
kevin.pouget@gmail.com
Thu Apr 21 14:32:00 GMT 2011
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
>
More information about the Gdb
mailing list