Re: Problems using psr.dd

[David Mosberger <davidm@napali.hpl.hp.com>]

>>>>> On Thu, 20 Nov 2003 18:52:33 +1100, Keith Owens <kaos@sgi.com> said:

  Keith> If there is enough RSE activity during the hardware
  Keith> breakpoint handler to flush the registers at the time of the
  Keith> breakpoint then returning with psr.db = 1 and psr.dd = 1 to
  Keith> step over the hardware breakpoint will not work.  The RSE
  Keith> activity that occurs as the flushed registers are restored is
  Keith> counted as a valid instruction, psr.dd is cleared, the
  Keith> original instruction is reexecuted and it trips again.

  Keith> Beware of doing too much activity in the hardware breakpoint
  Keith> handler.  I will create a patch against traps.c to detect a
  Keith> return with psr.dd set and issue loadrs to ensure that the
  Keith> RSE problem does not bite us.

I'm still not sure what's triggering the spurious fault:

 (1) The RSE activity generated for restoring the current frame, or
 (2) The RSE activity generated by the alloc instruction that eventually
     follows the instruction to which "rfi" returns to.

Unfortunately, the description of Erratum 11 isn't terribly clear to
me.  It says:

	... The rfi instruction is followed by additional instructions
	that generate register stack (RSE) activity (alloc, flushrs,
	br.ret).

I assume "followed" is referring to execution order, not program order
(i.e., inserting nop's around the "rfi" isn't going to do us any
good).  In your (original) case, the "rfi" is followed by a store
instruction, br.call, then alloc.  From reading the description, I
wouldn't have expected this to trigger the Erratum, but perhaps it
does.  Can someone clarify?

	--david