On Mon, Jul 27, 2009 at 05:41:52AM +0530, K.Prasad wrote: > Hi David, > I'm back with a new version of patches after a brief hiatus! > > After much deliberation about modifying the code to change the timing of > signal > delivery to user-space, it has been decided to retain the existing behaviour > i.e. SIGTRAP delivered to user-space after execution of causative instruction > although exception is raised before execution of it.
Ok. Except, presumably for ptrace, since changing that would break gdb. > One-shot behaviour will now be restricted only to ptrace > requests. Kernel-space and non-ptrace user-space requests will > result in persistent breakpoints. Ok. > 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? > - 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. > - Alternatives are i)use one-shot for all user-space requests ii)disable > signal > delivery for non-ptrace requests, allow the user-defined callback routine to > generate signal. > - Using one-shot for all user-space requests will break the > register/unregister > interface semantics. > - Disabling signal delivery for non-ptrace requests is one of the options > but will be a digression from x86 behaviour, or would require changes in x86 > code too. Even user-defined callback routines cannot deliver signal > before instruction execution. > > Considering all the above, we propose a behaviour that delivers the signal to > user-space after breakpoint execution. In due course, it will be good to have > ptrace on PPC64 follow the same behaviour. Um.. except we can't change ptrace semantics in this way. It could break existing users. -- 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