This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB Python API: stop/continue after breakpoint
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
>