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