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

David Gibson dwg at au1.ibm.com
Fri Jul 31 16:10:13 EST 2009


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


More information about the Linuxppc-dev mailing list