On Tue, Aug 04, 2009 at 02:23:16AM +0530, K.Prasad wrote:
> On Fri, Jul 31, 2009 at 04:10:13PM +1000, David Gibson wrote:
> > On Mon, Jul 27, 2009 at 05:41:52AM +0530, K.Prasad wrote:
> 
> <edited>
> 
> > > Reasons
> > > --------
> > > - Signal delivery before execution of instruction requires complex 
> > > workarounds
> > > - One of the plausible workarounds is a two-pass hw-breakpoint handler 
> > > which
> > >   delivers the signal after the first pass (with the breakpoints enabled).
> > >   In the second pass, it follows the existing semantics of
> > >   disable_hbp-->enable_ss-->single_step-->disable_ss-->enable_hbp.
> > 
> > Yes, that's the only way I can see to do it.
> > 
> > > - Possibility of nested exceptions is a problem here.
> > 
> > Ok, why?
> > 
> 
> Reason as described in the para below.
> 
> > > - Proper identification of a  second-pass of first exception and a new 
> > > nested
> > >   exception is difficult. Possibility of stray exceptions due to accesses 
> > > in
> > >   neighbouring memory regions of the breakpoint address further 
> > > complicates it.
> 
> To elaborate, consider a case where a user-space address 'x' is
> monitored for read or write, and the following happens (assume the
> existence of the two-pass method for signal delivery).
> 
> - Instruction 'i' attempts to read/write in address 'x'
> - hw-bkpt exception generated (pass I)
> - Signal generated and hw-bkpt exception returns to user-space
> - Signal is handled before 'i' is executed. Handler code reads/writes
>   data in 'x' again. Generates nested exception.
> - hw-breakpoint handler code is unable to distinguish if the new
>   exception is from signal handler (nested) or due to second-pass (as
>   per design above).

Ah, ok, I understand now.  Hrm.  I'll have to think about this.

-- 
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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to