Re: Regression

[Pedro Alves <pedro at codesourcery dot com>]

On Tuesday 10 February 2009 18:39:04, Mark Kettenis wrote:
> I've looked at the PR mentioned in the commi message, and I don't
> quite understand how the change to the signal command has anything to
> do with that.

Before Daniel's Daniel's patch, `signal_command' called `proceed'
like so:

+  proceed (oursig == TARGET_SIGNAL_0 ? (CORE_ADDR) -1 : stop_pc, oursig, 0);

For a signal != TARGET_SIGNAL_0, say signal FOO, that's effectivelly this:

 proceed (stop_pc, oursig, 0);



void
proceed (CORE_ADDR addr, enum target_signal siggnal, int step)
{
(...)
  if (addr == (CORE_ADDR) -1)
    {
      if (pc == stop_pc && breakpoint_here_p (pc) 
	  && execution_direction != EXEC_REVERSE)
	/* There is a breakpoint at the address we will resume at,
	   step one instruction before inserting breakpoints so that
	   we do not stop right away (and report a second hit at this
	   breakpoint).

	   Note, we don't do this in reverse, because we won't
	   actually be executing the breakpoint insn anyway.
	   We'll be (un-)executing the previous instruction.  */

	oneproc = 1;
      else if (gdbarch_single_step_through_delay_p (gdbarch)
	       && gdbarch_single_step_through_delay (gdbarch,
						     get_current_frame ()))
	/* We stepped onto an instruction that needs to be stepped
	   again before re-inserting the breakpoint, do so.  */
	oneproc = 1;
    }
  else
    {
      regcache_write_pc (regcache, addr);
    }
(...)

This messed with syscall restarting on linux, since it was
writing the PC.  

Notice that the (addr != (CORE_ADDR) -1) code path doesn't
set `oneproc', hence, ends up *not* removing
breakpoints, and *not* single-stepping, even if we were stopped
at a breakpoint.  That is what I call the "jump" behaviour --- a jump
to $PC hits a breakpoint at $PC.

After Daniel's change, signal_command does this unconditionaly:

 proceed ((CORE_ADDR) -1, oursig, 0);

Which means we now go through the "(addr == (CORE_ADDR) -1)"
branch above.  This avoided the regcache_write_pc call.   But, it also
sets `oneproc' because in this case, there's a breakpoint at
stop_pc, and PC is still at stop_pc.  That will make us remove
breakpoints from the inferior, and call `resume' with step=1.
The part that's breakpoint the BSDs is the fact that we now
remove breakpoints from the inferior.

-- 
Pedro Alves