From: David Gibson <dwg@au1•ibm.com>
To: "K.Prasad" <prasad@linux•vnet.ibm.com>
Cc: Michael Neuling <mikey@neuling•org>,
Benjamin Herrenschmidt <benh@au1•ibm.com>,
linuxppc-dev@ozlabs•org, paulus@samba•org,
Alan Stern <stern@rowland•harvard.edu>,
Roland McGrath <roland@redhat•com>
Subject: Re: [Patch 0/6] [Patch 0/6] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver VIII
Date: Fri, 31 Jul 2009 16:10:13 +1000 [thread overview]
Message-ID: <20090731061013.GG3950@yookeroo.seuss> (raw)
In-Reply-To: <20090727001152.GA13562@in.ibm.com>
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
next prev parent reply other threads:[~2009-07-31 6:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-27 0:11 [Patch 0/6] [Patch 0/6] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver VIII K.Prasad
2009-07-31 6:10 ` David Gibson [this message]
2009-08-03 16:14 ` Luis Machado
2009-08-03 20:53 ` K.Prasad
2009-08-05 2:08 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090731061013.GG3950@yookeroo.seuss \
--to=dwg@au1$(echo .)ibm.com \
--cc=benh@au1$(echo .)ibm.com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=mikey@neuling$(echo .)org \
--cc=paulus@samba$(echo .)org \
--cc=prasad@linux$(echo .)vnet.ibm.com \
--cc=roland@redhat$(echo .)com \
--cc=stern@rowland$(echo .)harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox