This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Handle SIGINT in Python


Hi,

On Jan 11, 2012, at 4:06 PM, Tom Tromey wrote:

>>>>>> "Yit" == Khoo Yit Phang <khooyp@cs.umd.edu> writes:
> 
> Yit> I've written a patch to GDB's Python support to allow SIGINT to
> Yit> interrupt a running script to address the bug
> Yit> http://sourceware.org/bugzilla/show_bug.cgi?id=13265 (I've attached my
> Yit> patch to that page).
> 
> See my other note about how to send the patch; and my other other note
> about copyright assignments.

I'll attach a patch in a moment.

> I don't understand why this code doesn't just pass the old signal
> handler as an argument to the cleanup function.  I think that would be
> more readable.
> What happens when the Python code calls back into gdb?
> We do this in many places in gdb/python/*.c.
> It seems to me that you'd have to temporarily push gdb's SIGINT handler
> again.

It is not the old signal handler that's being restored. My implementation handles the following sequence of events:

... SIGINT is handle_sigint_orig ...

(gdb) python

... SIGINT is python_handle_sigint

>>>  gdb.execute("something that changes the SIGINT handler to handle_sigint_new")

... python_handle_sigint is suspended and SIGINT is restored to handle_sigint_orig 
... gdb.execute runs and changes SIGINT is updated to handle_sigint_new
... python_handle_sigint is resumed, but python_saved_sigint_handler is now handle_sigint_new

>>> ^D

... SIGINT is handle_sigint_new, *not* handle_sigint_orig

(gdb)


> Could we possibly solve this problem without constantly resetting the
> SIGINT handler?  Maybe via a combination of a global flag plus a call
> into Python from handle_sigint?

It is possible, I just need a way to call PySet_Interrupt. But it seems to be that it would require adding hooks to events-top.c and, which seems like a separate project.

> Our python->gdb exception story is not super.  And, we lose information
> in the round trip.  This might (or might not...) be a prerequisite to
> solving this problem.

I don't think it's a problem, unless for nested calls to python like "py gdb.execute('py ...')".

Yit
January 11, 2012


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]