Re: [Patch 0/6] [Patch 0/6] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver VIII

["K.Prasad" <prasad@linux.vnet.ibm.com>]

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

Thanks,
K.Prasad