Re: RFC: Do not call write_pc for "signal SIGINT"

[Pedro Alves <pedro at codesourcery dot com>]

On Monday 17 November 2008 21:55:01, Daniel Jacobowitz wrote:

> 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. 

This may help explain it better:

/* Set the program counter for process PTID to PC.  */

static void
i386_linux_write_pc (struct regcache *regcache, CORE_ADDR pc)
{
  regcache_cooked_write_unsigned (regcache, I386_EIP_REGNUM, pc);

  /* We must be careful with modifying the program counter.  If we
     just interrupted a system call, the kernel might try to restart
     it when we resume the inferior.  On restarting the system call,
     the kernel will try backing up the program counter even though it
     no longer points at the system call.  This typically results in a
     SIGSEGV or SIGILL.  We can prevent this by writing `-1' in the
     "orig_eax" pseudo-register.

     Note that "orig_eax" is saved when setting up a dummy call frame.
     This means that it is properly restored when that frame is
     popped, and that the interrupted system call will be restarted
     when we resume the inferior on return from a function call from
     within GDB.  In all other cases the system call will not be
     restarted.  */
  regcache_cooked_write_unsigned (regcache, I386_LINUX_ORIG_EAX_REGNUM, -1);
}

-- 
Pedro Alves