From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28949 invoked by alias); 11 Jan 2012 21:46:17 -0000 Received: (qmail 28940 invoked by uid 22791); 11 Jan 2012 21:46:16 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from router-304.cs.umd.edu (HELO bacon.cs.umd.edu) (128.8.127.145) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Jan 2012 21:45:58 +0000 Received: from wireless-206-196-163-53.umd.edu (wireless-206-196-163-53.umd.edu [206.196.163.53]) (Authenticated sender: khooyp) by bacon.cs.umd.edu (Postfix) with ESMTPSA id A0CDCB40395; Wed, 11 Jan 2012 16:45:52 -0500 (EST) Subject: Re: Handle SIGINT in Python Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Khoo Yit Phang In-Reply-To: Date: Wed, 11 Jan 2012 21:49:00 -0000 Cc: Khoo Yit Phang , gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <1FE2845A-162C-48D7-A3D0-C0F2D6DFA09B@cs.umd.edu> References: To: Tom Tromey X-CSD-MailScanner-ID: A0CDCB40395.A97E4 X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-50, required 5, autolearn=not spam, ALL_TRUSTED -50.00) X-CSD-MailScanner-From: khooyp@cs.umd.edu X-CSD-MailScanner-Watermark: 1326923152.84036@6XQgnlNcGPgBEBn7VpYIkw Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00382.txt.bz2 Hi, On Jan 11, 2012, at 4:06 PM, Tom Tromey wrote: >>>>>> "Yit" =3D=3D Khoo Yit Phang writes: >=20 > 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=3D13265 (I've attache= d my > Yit> patch to that page). >=20 > 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 h= andles 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_sigin= t_new") ... python_handle_sigint is suspended and SIGINT is restored to handle_sigi= nt_orig=20 ... 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 gd= b.execute('py ...')". Yit January 11, 2012