This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: Do not call write_pc for "signal SIGINT"
- From: Daniel Jacobowitz <drow at false dot org>
- To: gdb-patches at sourceware dot org
- Cc: Michael Snyder <msnyder at vmware dot com>
- Date: Tue, 20 Jan 2009 10:32:37 -0500
- Subject: Re: RFC: Do not call write_pc for "signal SIGINT"
- References: <20080828155520.GA23110@caradoc.them.org> <48B6E9F4.5080403@vmware.com> <20080828181841.GA30866@caradoc.them.org> <48B6EFBD.2090203@vmware.com> <20080828223232.GA6407@caradoc.them.org> <20081117215501.GA19975@caradoc.them.org>
On Mon, Nov 17, 2008 at 04:55:01PM -0500, Daniel Jacobowitz wrote:
> Here it is with a testcase.
>
> To recap: there is a tricky bug in signal_command. If any non-zero
> signal is specified, it performs a jump to the current address instead
> of just resuming there. This causes any pending system call to be
> interrupted, in a way that leaves a kernel-internal value in the
> return value register. If we just delete that code, and the FIXME
> that goes with it, the right thing happens: instead of "Unknown
> error 514", the system call returns EINTR and the loop continues.
> 2008-11-17 Daniel Jacobowitz <dan@codesourcery.com>
>
> PR gdb/2241
> * infcmd.c (signal_command): Do not specify a resume PC.
>
> 2008-11-17 Daniel Jacobowitz <dan@codesourcery.com>
>
> PR gdb/2241
> * gdb.base/interrupt.c (sigint_handler): New.
> (main): Install a SIGINT handler if SIGNALS is defined. Exit
> on error.
> * gdb.base/interrupt.exp: Define SIGNALS unless gdb,nosignals.
> Test "signal SIGINT".
I have checked this in.
--
Daniel Jacobowitz
CodeSourcery