This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/4]: Handle SIGINT under Python by raising KeyboardInterrupt
- From: Khoo Yit Phang <khooyp at cs dot umd dot edu>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Khoo Yit Phang <khooyp at cs dot umd dot edu>, gdb-patches at sourceware dot org
- Date: Wed, 25 Jul 2012 13:36:36 -0400
- Subject: Re: [PATCH 2/4]: Handle SIGINT under Python by raising KeyboardInterrupt
- References: <E7EE97CE-30A6-4C4A-8606-CB86F204207D@cs.umd.edu> <87ipdbiwcx.fsf@fleche.redhat.com>
Hi,
On Jul 25, 2012, at 1:28 PM, Tom Tromey wrote:
>>>>>> "Yit" == Khoo Yit Phang <khooyp@cs.umd.edu> writes:
>
> Yit> +static sig_t gdbpy_saved_sigint_handler;
>
> Rather than use a global, it seems a bit better to me to store the old
> signal handler in the python_env, and then restore it from there.
Actually, that's not the behavior I'm going for: instead of restoring the old signal handler, I'm preserving whatever changes to the signal handler that has been made in the nested Python context (if it can ever happen). E.g.:
(gdb) ... at this point, it's the FOO handler ...
(gdb) py
>>> gdb.execute("... something that changes the signal handler to BAR ...")
>>> ^D
(gdb) ... at this point, it's the BAR handler ...
> Yit> + gdbpy_suspend_sigint_handler ();
>
> This addition handles one instance of the python->gdb transition, but
> there are many more to fix.
I think it's okay to handle just the long-running python->gdb transitions, or those where SIGINT is critical to correct functionality. Are there other long-running python->gdb transitions that I should fix?
Yit
July 25, 2012