[Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces

[David Gibson]

On Tue, Aug 04, 2009 at 02:29:38AM +0530, K.Prasad wrote:
> On Fri, Jul 31, 2009 at 04:16:46PM +1000, David Gibson wrote:
> > On Mon, Jul 27, 2009 at 05:43:17AM +0530, K.Prasad wrote:
[snip]
> > > +	/* Verify if dar lies within the address range occupied by the symbol
> > > +	 * being watched. Since we cannot get the symbol size for
> > > +	 * user-space requests we skip this check in that case
> > > +	 */
> > > +	if (is_kernel &&
> > > +	    !((bp->info.address <= dar) &&
> > > +	     (dar <= (bp->info.address + bp->info.symbolsize))))
> > > +		/*
> > > +		 * This exception is triggered not because of a memory access on
> > > +		 * the monitored variable but in the double-word address range
> > > +		 * in which it is contained. We will consume this exception,
> > > +		 * considering it as 'noise'.
> > > +		 */
> > > +		goto out;
> > > +
> > > +	(bp->triggered)(bp, regs);
> > 
> > It bothers me that the trigger function is executed before the
> > trapping instruction, but the SIGTRAP occurs afterwards.  Since
> > they're both responses to the trap, it seems logical to me that they
> > should occur at the same time (from the trapping program's point of
> > view, at least).
> > 
> 
> How about moving the triggered function to the single-step handler code
> for both kernel- and user-space?
> 
> That would make it behave like a trigger-after-execute (and synchronised
> with the signal-delivery timing).

I think that would be an improvement, yes.  I definitely think the
SIGTRAP and the callback function should happen at the same time in
all cases.  Possibly even have the callback function issue the SIGTRAP
rather than special casing that.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson