linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "K.Prasad" <prasad@linux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Michael Neuling <mikey@neuling.org>,
	Benjamin Herrenschmidt <benh@au1.ibm.com>,
	shaggy@linux.vnet.ibm.com,
	Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>,
	Will Deacon <will.deacon@arm.com>, David Gibson <dwg@au1.ibm.com>,
	linuxppc-dev@ozlabs.org, Alan Stern <stern@rowland.harvard.edu>,
	paulus@samba.org, Roland McGrath <roland@redhat.com>
Subject: Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
Date: Tue, 23 Feb 2010 16:27:15 +0530	[thread overview]
Message-ID: <20100223105715.GA17358@in.ibm.com> (raw)
In-Reply-To: <20100222131746.GA3228@in.ibm.com>

On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote:
> On Sun, Feb 21, 2010 at 02:01:37AM +0100, Frederic Weisbecker wrote:
> > On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote:
[snipped]
> > Also, do you think addr/len/type is enough to abstract out
> > any ppc breakpoints?
> > 
> > This looks enough to me to express range breakpoints and
> > simple breakpoints. But what about value comparison?
> > (And still, there may be other trickier implementations
> > I don't know in ppc).
> > 
> 
> The above implementation is for PPC64 architecture that supports only
> 'simple' breakpoints of fixed length (no range breakpoints, no value
> comparison). More on that below.
>

Looks like I forgot the 'more on that below' part :-)....here are some
thoughts...

Architectures like PPC Book-E have support for a variety of
sophisticated debug features and our generic framework, in its present
form, cannot easily port itself to these processors. In order to extend
the framework for PPC Book-E, I intend the following to begin with:

- Implement support for data breakpoints through DAC registers with all
  the 'bells and whistles'...support for instruction breakpoints through
  IAC can come in later (without precluding its use through ptrace).

- Embed the flags/variables to store DVC, masked address mode, etc. in
  'struct arch_hw_breakpoint', which will be populated by the user of
  register_breakpoint interface.

Apart from the above extensions to the framework, changes in the generic
code would be required as described in an earlier LKML mail (ref:
message-id: 20091127190705.GB18408@in.ibm.com)....relevant contents
pasted below:

"I think the register_<> interfaces can become wrappers around functions
that do the following:

- arch_validate(): Validate request by invoking an arch-dependant
  routine. Proceed if returned valid.
- arch-specific debugreg availability: Do something like
  if (arch_hw_breakpoint_availabile())
        bp = perf_event_create_kernel_counter();

  perf_event_create_kernel_counter()--->arch_install_hw_breakpoint();

This way, all book-keeping related work (no. of pinned/flexible/per-cpu)
will be moved to arch-specific files (will be helpful for PPC Book-E
implementation having two types of debug registers). Every new
architecture that intends to port to the new hw-breakpoint
implementation must define their arch_validate(),
arch_hw_breakpoint_available() and an arch_install_hw_breakpoint(),
while the hw-breakpoint code will be flexible enough to extend itself to
each of these archs."

Let me know what you think of the above.

Thanks,
K.Prasad

  reply	other threads:[~2010-02-23 10:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-15  5:56 [Patch 0/1] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XIII K.Prasad
2010-02-15  5:59 ` [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64 K.Prasad
2010-02-21  1:01   ` Frederic Weisbecker
2010-02-22 13:17     ` K.Prasad
2010-02-23 10:57       ` K.Prasad [this message]
2010-02-26 17:52         ` Frederic Weisbecker
2010-02-26  1:58       ` Frederic Weisbecker
2010-03-08 23:57         ` David Gibson
2010-03-09  2:14         ` K.Prasad
  -- strict thread matches above, loose matches on Subject: below --
2010-03-08 18:12 [Patch 0/1] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XIV K.Prasad
2010-03-08 18:14 ` [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64 K.Prasad
2010-03-12  6:19   ` Benjamin Herrenschmidt
2010-03-15  6:29     ` K.Prasad
2010-04-07  8:03       ` Benjamin Herrenschmidt
2010-04-14  3:53         ` K.Prasad
2010-03-23  5:33   ` Paul Mackerras
2010-03-23  7:28     ` K.Prasad
2010-01-21  8:46 [Patch 0/1] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XII K.Prasad
2010-01-21  8:49 ` [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64 K.Prasad
2010-01-19  9:12 [Patch 0/1] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XI K.Prasad
2010-01-19  9:14 ` [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64 K.Prasad
2009-12-11 16:04 K.Prasad
2009-12-14  0:56 ` Roland McGrath
2009-12-14 18:03   ` K.Prasad
2009-12-14 19:26     ` Roland McGrath
2009-12-17 19:03       ` K.Prasad
2010-01-19  9:40         ` K.Prasad
2010-01-19 10:03           ` Roland McGrath
2010-01-22  7:14             ` K.Prasad

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=20100223105715.GA17358@in.ibm.com \
    --to=prasad@linux.vnet.ibm.com \
    --cc=benh@au1.ibm.com \
    --cc=dwg@au1.ibm.com \
    --cc=fweisbec@gmail.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mahesh@linux.vnet.ibm.com \
    --cc=mikey@neuling.org \
    --cc=paulus@samba.org \
    --cc=roland@redhat.com \
    --cc=shaggy@linux.vnet.ibm.com \
    --cc=stern@rowland.harvard.edu \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).