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